OAuth Stuff

[DavidBuchanan314]

Creating this issue to track OAuth stuff.

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)

[DavidBuchanan314]

Confidential Client Authentication is also a thing, but for a first-pass I will not support confidential clients

[DavidBuchanan314]

note to self: be mindful of CSRF on form submission

[DavidBuchanan314]

We have to request and validate client metadata, per https://github.com/bluesky-social/proposals/tree/main/0004-oauth#client-metadata

This is a bit annoying since the request needs to happen pre-auth, so we'll have to be aggressive about rate limiting, and maybe even cache the result?

It's not totally clear where the validation is support to happen. on PAR? when the client loads the auth endpoint? after the user enters their creds on the auth endpoint?

the latter could let us gate the metadata request behind successful auth

[DavidBuchanan314]

Immediate agenda:

• Properly understand PKCE. I understand it conceptually but not the mechanics of how it functions.

• Make login actually do something, figure out session cookies

[DavidBuchanan314]

re: web auth session cookies

We could use JWT for this again and be "stateless", but really, this needs statefulness. Using a uuid token and a database column is easier to get my head around. I'll store the associated state in a CBOR blob for now, so it's more extensible without changing the db schema.

Remember to set them as http-only!

[DavidBuchanan314]

I was previously gonna reuse the /oauth/authorize route for both authentication and authorization, but now I'm confusing myself... It's too overloaded.

/oauth/authorize is the initial "entrypoint" the client redirects to (with a GET).

/oauth/authorize should check if there's an existing auth session cookie. If so, display the actual authorization prompt directly. If the user accepts, it should POST to /oauth/authorize

If not, redirect to /oauth/authenticate, which will present the password prompt. It should POST to /oauth/authenticate, and on success redirect back to /oauth/authorize which should show the authz prompt.

[DavidBuchanan314]

I'll also need to have a db table to track which users have authorized which scopes to which app