OAuth

[erlend-sh]

Status: See OAuth outline below.

OAuth is the default method of authentication in atproto.

The task at hand is neatly described by the parallel effort in millipds:

Docs: https://atproto.com/specs/oauth

Initial proposal: https://github.com/bluesky-social/proposals/tree/main/0004-oauth

Client implementations (useful for reference):

https://github.com/mary-ext/atcute/tree/trunk/packages/oauth/browser-client
https://github.com/bluesky-social/atproto/tree/main/packages/oauth
Incomplete list of specific things we need to implement:

• DPoP (involves tracking jti reuse - needs DB)
• PAR (involves associating auth requests with UUIDs, with some TTL - could plausibly stay in-memory)
• PKCE
• An actual login webui, allowing the user to grant the requested scopes. (likely involves associating session state with a cookie - needs DB)

Some of this is already done in atrium: https://github.com/sugyan/atrium/tree/main/atrium-oauth

There are two additional PRs pertaining to OAuth still pending, though I’m not sure if they’re necessary for rsky’s purposes:

• Oauth session sugyan/atrium#242
• [WIP] feat: agent rework sugyan/atrium#243

[afbase]

@erlend-sh @rudyfraser

1. does it make sense to contribute and finish the atrium-oauth and then bring that into rsky? or should rsky finish it's implementation, independent of atrium?
2. @rudyfraser How high of a priority is OAuth relative to other things you'd like to see developed?

[rudyfraser]

2. @rudyfraser How high of a priority is OAuth relative to other things you'd like to see developed?

Oauth is pretty high and is green field. I'm working on a relay impl that'll likely take a few weeks as I juggle other non-development things for Blacksky. I know Rip is working on all things related to ImportRepos.

As Erlend mentioned though, Oauth is important for connecting to the rest of the atproto ecosystem and new apps. So if you have the capacity and desire to take on even part of this it'd be greatly appreciated.

1. does it make sense to contribute and finish the atrium-oauth and then bring that into rsky? or should rsky finish it's implementation, independent of atrium?

Atrium is primarily an API client/sdk library so I can't imagine there's much dependencies between what rsky needs on the PDS side. There are official implementation guides for client implementations but I don't know that one exists for PDS implementations (probably because there are far fewer production-ready PDS impls) which has been the primary barrier to my diving into this personally. I'd personally take a "translate whatever the TS impl is doing" approach for this. That'd make it easier for me to review as well.

If in addition to building this and testing it, you could also provide some minimal documentation like you've done for other contributions that'd be awesome.

[afbase]

I'll start with outlining the work to be done and chip away on it bit by bit!

[TheRipperoni]

I was actually thinking about this being the next thing I took a look at after import and account migration related work was finished, so I'd love to see the outline!

[afbase]

OAuth Outline

1. Create rsky-oauth workspace member
   • Prioritize the development of the following modules:
     • oauth-types
     • oauth-provider and its "modules":
       • access-token
       • account
       • assets
       • client
       • device
       • dpop
       • errors
       • lib
       • metadata
       • oidc
       • output
       • replay
       • request
       • signer
       • token
     • oauth-client
2. support DPoP in validate_access_token in rsky-pds/src/auth_verifier.rs
   • add tests for DPoP validation in rsky-pds/tests/auth_verifier_tests.rs
3. It may behoove us to create a published crate for Client ID Metadata Document RFC 9449
4. Add an /.well-known/oauth-protected-resource endpoint to rsky-pds to provide Server Metadata
5. Instead of implementing our own jwk/jose/jwt library, I'd like to see if we can utilize an existing JWT library for the JWKS/JOSE stuff (e.g. Keats/jsonwebtoken; I see we use jwt-simple as well), and see about writing code to manage jti nonces serparately.
6. Finally I think once we have oauth-client and oauth-provider, we could create some example applications that demonstrate how to make a variety of clients: browser, desktop, etc.

[afbase]

@TheRipperoni What do you think? are there parts of this you think we need to change?

some of those workspace members will be hefty. Happy to tackle it together! Are there particular parts you'd like to work on? I'm happy to tackle other parts.

[afbase]

I'm going to start work on the oauth-types "module"

[TheRipperoni]

I'm going to start work on the oauth-types "module"
Sounds good! I'll take a look into the provider module when I get the chance. Will comment when that happens