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 atrium-rs/atrium#242
• feat: OAuth session atrium-rs/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

[afbase]

I will have a PR ready for oauth provider before end of month. there's quite of bit of types and I'm going back and forth with the typescript reference code base on what I'm making.

[TheRipperoni]

I will have a PR ready for oauth provider before end of month. there's quite of bit of types and I'm going back and forth with the typescript reference code base on what I'm making.

Do you have a forked repository for it? I'd be happy to contribute

[afbase]

https://github.com/afbase/rsky/tree/afbase/oauth-types - where i left off last week

[TheRipperoni]

https://github.com/afbase/rsky/tree/afbase/oauth-types - where i left off last week

Much appreciated

[TheRipperoni]

https://github.com/afbase/rsky/tree/afbase/oauth-types - where i left off last week

Since you are covering types at the moment, I think I'm able to start off by tackling the general skeleton for the Stores and Managers the typescript implementation utilizes

[afbase]

I should have something ready with all the types by Tuesday. I plan to push something up later into the weekend.

[TheRipperoni]

I should have something ready with all the types by Tuesday. I plan to push something up later into the weekend.

That would be perfect. I have some skeleton ready to go, including the well-known, but need the types to properly utilize it

[afbase]

@TheRipperoni

Important

This is a lot of code. I definitely used AI to generate a good heap of it 😓 and put in my own bits here and there as I saw fit.

https://github.com/afbase/rsky/tree/afbase/oauth-types - is just about ready. 85% test pass rate right now and I'm going to finish the testing tomorrow (Tuesday). but i think it's just about ready for trying things out on your end.

[TheRipperoni]

@TheRipperoni

Important

This is a lot of code. I definitely used AI to generate a good heap of it 😓 and put in my own bits here and there as I saw fit.

https://github.com/afbase/rsky/tree/afbase/oauth-types - is just about ready. 85% test pass rate right now and I'm going to finish the testing tomorrow (Tuesday). but i think it's just about ready for trying things out on your end.

Sounds good, I'll start then. I'll give it a scan over as working to determine if there is anything off with it that the AI did. Thanks!

[afbase]

@TheRipperoni i've updated my branch with more tests. the OAuthAuthorizationRequestJar serialization was manually implemented and has better testing now and i made some other test and code fixes as well. I'm at ~96% test passing. I'll finish the rest of it tomorrow!

[TheRipperoni]

@TheRipperoni i've updated my branch with more tests. the OAuthAuthorizationRequestJar serialization was manually implemented and has better testing now and i made some other test and code fixes as well. I'm at ~96% test passing. I'll finish the rest of it tomorrow!

Sounds good! I was working today on building out the general skeleton for the rest. The biggest thing still is deciding how to go about the actual jwk part, as that we have to deviate more from the typescript implementation on as the library used doesn't really have a 1:1 in rust

[afbase]

@TheRipperoni i've updated my branch with more tests. the OAuthAuthorizationRequestJar serialization was manually implemented and has better testing now and i made some other test and code fixes as well. I'm at ~96% test passing. I'll finish the rest of it tomorrow!

Sounds good! I was working today on building out the general skeleton for the rest. The biggest thing still is deciding how to go about the actual jwk part, as that we have to deviate more from the typescript implementation on as the library used doesn't really have a 1:1 in rust

There is jwk-rs that appears to work with jsonwebtoken which I use here and there in my oauth-types.

I'm happy to implement the rest of the corresponding jwk module if it would be of any help. I focused mainly on Jwt as it was a type that the oauth-types in the typescript codebase referred to a Jwt type.

[TheRipperoni]

@TheRipperoni i've updated my branch with more tests. the OAuthAuthorizationRequestJar serialization was manually implemented and has better testing now and i made some other test and code fixes as well. I'm at ~96% test passing. I'll finish the rest of it tomorrow!

Sounds good! I was working today on building out the general skeleton for the rest. The biggest thing still is deciding how to go about the actual jwk part, as that we have to deviate more from the typescript implementation on as the library used doesn't really have a 1:1 in rust

There is jwk-rs that appears to work with jsonwebtoken which I use here and there in my oauth-types.

I'm happy to implement the rest of the corresponding jwk module if it would be of any help. I focused mainly on Jwt as it was a type that the oauth-types in the typescript codebase referred to a Jwt type.

I'll take a look today and let you know!

[afbase]

@TheRipperoni - my branch is testing at 100% on commit 72b189f

Summary of Changes to rsky-oauth Codebase from f274ce9..72b189f

Overview of Changes Made Today (Wed Feb 26)

The changes focus on several areas across the OAuth implementation:

• Removing Documentation: Some doctests were old and the unit tests are sufficient for usage
• Serialization Improvements: Custom serialization/deserialization implementations added to several OAuth request types
• URI Validation: Fixed validation bug for private-use URIs according to RFC standards

File-by-File Changes

src/jwk/jwt.rs

• Removed old documentation tests from the verify_with_options method

src/oauth_types/oauth_authorization_code_grant_token_request.rs

• Replaced default Serde derive with custom serialization/deserialization
• Fixed tests to use a valid code verifier meeting length requirements

src/oauth_types/oauth_authorization_request_jar.rs

• Removed lengthy documentation examples

src/oauth_types/oauth_client_credentials_grant_token_request.rs

• Added custom serialization/deserialization logic
• improved tests for serialization cases

src/oauth_types/oauth_password_grant_token_request.rs

• Implemented custom serialization/deserialization
• Added validation for empty username/password fields

src/oauth_types/oauth_refresh_token_grant_token_request.rs

• Added custom serialization/deserialization logic
• Improved error handling for refresh token validation

src/oauth_types/oauth_token_request.rs

• Replaced tagged enum-based serialization with custom implementation
• Enhanced deserialization to properly handle different grant types
• Added comprehensive tests for all request types

src/oauth_types/oauth_redirect_uri.rs and src/oauth_types/uri.rs

• Improved validation for private-use URIs according to RFC 8252
• Enhanced error messages for various URI validation failures
• Fixed validation to properly handle path components

src/oauth_types/oauth_token_identification.rs

• Removed from_form and to_form methods. I blame AI for being very eager to do url encoding.

[TheRipperoni]

@TheRipperoni - my branch is testing at 100% on commit 72b189f

Summary of Changes to rsky-oauth Codebase from f274ce9..72b189f

Overview of Changes Made Today (Wed Feb 26)

The changes focus on several areas across the OAuth implementation:

* **Removing Documentation**: Some doctests were old and the unit tests are sufficient for usage

* **Serialization Improvements**: Custom serialization/deserialization implementations added to several OAuth request types

* **URI Validation**: Fixed validation bug for private-use URIs according to RFC standards

File-by-File Changes

src/jwk/jwt.rs

* Removed old documentation tests from the `verify_with_options` method

src/oauth_types/oauth_authorization_code_grant_token_request.rs

* Replaced default Serde derive with custom serialization/deserialization

* Fixed tests to use a valid code verifier meeting length requirements

src/oauth_types/oauth_authorization_request_jar.rs

* Removed lengthy documentation examples

src/oauth_types/oauth_client_credentials_grant_token_request.rs

* Added custom serialization/deserialization logic

* improved tests for serialization cases

src/oauth_types/oauth_password_grant_token_request.rs

* Implemented custom serialization/deserialization

* Added validation for empty username/password fields

src/oauth_types/oauth_refresh_token_grant_token_request.rs

* Added custom serialization/deserialization logic

* Improved error handling for refresh token validation

src/oauth_types/oauth_token_request.rs

* Replaced tagged enum-based serialization with custom implementation

* Enhanced deserialization to properly handle different grant types

* Added comprehensive tests for all request types

src/oauth_types/oauth_redirect_uri.rs and src/oauth_types/uri.rs

* Improved validation for private-use URIs according to RFC 8252

* Enhanced error messages for various URI validation failures

* Fixed validation to properly handle path components

src/oauth_types/oauth_token_identification.rs

* Removed `from_form` and `to_form` methods.  I blame AI for being very eager to do url encoding.

Sounds great! It's going to take me a couple days to get started, so if you had anything you wanted to work on it in the meanwhile go for it

[TheRipperoni]

@TheRipperoni - my branch is testing at 100% on commit 72b189f

Summary of Changes to rsky-oauth Codebase from f274ce9..72b189f

Overview of Changes Made Today (Wed Feb 26)

The changes focus on several areas across the OAuth implementation:

* **Removing Documentation**: Some doctests were old and the unit tests are sufficient for usage

* **Serialization Improvements**: Custom serialization/deserialization implementations added to several OAuth request types

* **URI Validation**: Fixed validation bug for private-use URIs according to RFC standards

File-by-File Changes

src/jwk/jwt.rs

* Removed old documentation tests from the `verify_with_options` method

src/oauth_types/oauth_authorization_code_grant_token_request.rs

* Replaced default Serde derive with custom serialization/deserialization

* Fixed tests to use a valid code verifier meeting length requirements

src/oauth_types/oauth_authorization_request_jar.rs

* Removed lengthy documentation examples

src/oauth_types/oauth_client_credentials_grant_token_request.rs

* Added custom serialization/deserialization logic

* improved tests for serialization cases

src/oauth_types/oauth_password_grant_token_request.rs

* Implemented custom serialization/deserialization

* Added validation for empty username/password fields

src/oauth_types/oauth_refresh_token_grant_token_request.rs

* Added custom serialization/deserialization logic

* Improved error handling for refresh token validation

src/oauth_types/oauth_token_request.rs

* Replaced tagged enum-based serialization with custom implementation

* Enhanced deserialization to properly handle different grant types

* Added comprehensive tests for all request types

src/oauth_types/oauth_redirect_uri.rs and src/oauth_types/uri.rs

* Improved validation for private-use URIs according to RFC 8252

* Enhanced error messages for various URI validation failures

* Fixed validation to properly handle path components

src/oauth_types/oauth_token_identification.rs

* Removed `from_form` and `to_form` methods.  I blame AI for being very eager to do url encoding.

Sounds great! It's going to take me a couple days to get started, so if you had anything you wanted to work on it in the meanwhile go for it

Coming back to work on this now

[TheRipperoni]

Well known and basic endpoint skeleton is setup

https://github.com/TheRipperoni/rsky/tree/well-known

[TheRipperoni]

Have much more ready to go, just need to validate it carefully

[erlend-sh]

Would love to see all this work being upstreamed into rsky proper soon, as that will enable my collaborators to contribute towards #67

[TheRipperoni]

Had to step back for a moment, but will try to circle back to pushing what I have thus far by end of the week

[TheRipperoni]

Spending development time this week focused only on this to get it out

[TheRipperoni]

Just push a lot into my OAuth fork. Was able to test PAR api earlier, and well-known functions. Going to continue development this week

[TheRipperoni]

Implementing a chance to the AccountManager to better reflect the typescript reference. Once that's done tomorrow, should be able to bring most of it all together

[TheRipperoni]

Still working on it in this branch in particular
https://github.com/TheRipperoni/rsky/tree/oauth-implementation

[TheRipperoni]

Had a bit of a break, but have authorize, accept, reject, sign-in fairly close to working as expected. Added integration tests for them as well

#90

[TheRipperoni]

Currently blocked on this

#96