Repository navigation
Implement OAuth relying on Authlib #1240
Description
Activity
Hi @yannj-fr, thanks for checking in and offering your help!
Reducing maintenance cost sounds like a great objective indeed!
I'm not familiar w/ Authlib (not sure I understand their licensing model, looks like it takes a commercial license to get on their security mailing list). At what level were you thinking of integrating it?
The pattern used in #882 (extending httpx.Auth) could potentially be used, even outside the SDK itself. Whether things make it into the SDK might instead be a question for the protocol itself / e.g. this SEP suggests adding client credentials
Discussed with the maintainers there:
The license is open source for everyone, there is a possibility to gain support through commercial license.
They provide a httpx implementation here https://docs.authlib.org/en/latest/client/httpx.htmlMy idea is to contribute to authlib for all rfc we need so we have minimum support to do here
Reacted by Olivier ChafikI proposed it on Discord, so... I'm happy.
The license is BSD-3-Clause, the same as Starlette.
Reacted by Olivier ChafikI'm onboard with this. My one wish would be to do it in a way that's pluggable, so if someone does not want to use authlib, they can swap in something else.
the httpx approach seems like a good hook to make this generic.
For example, if we are prototyping around an RFC not supported in authlib, I'd like to be able to easily swap in an implementation rather than have to patch authlib and cross-link etc.
Reacted by Olivier ChafikI suggest we modernize and modularize the OAuthProvider implementation with the following goals in mind:
Composable workflow: Design the provider to expose a simple, override-friendly flow. This allows contributors and integrators to easily test or swap in custom behavior without duplicating the whole logic.
Leverage Authlib: Instead of implementing OAuth/OIDC specs manually, we should rely on authlib to handle protocol compliance. This reduces maintenance burden and ensures adherence to standards, unless we're handling custom flow control.
Configurable flows: Structure parameterization so that each officially supported OAuth flow (e.g., Authorization Code, Client Credentials, etc.) can be easily configured via clean, declarative settings.
Extensibility: Leave room for additional/custom parameters in the configuration. This makes it easier to extend or override specific parts of the provider logic while keeping the configuration accessible and consistent.
Reacted by cwegener and keurcienThat all sounds great to me
Reacted by Felix WeinbergerHi maintainers — I'd appreciate a review when you have time.
This PR is intentionally narrowly scoped and low-risk. It introduces a minimal
AuthProviderprotocol and an Authlib-basedhttpx.Authadapter without modifying any existing OAuth behavior or public interfaces.The goal is to establish a safe foundation for #1240 while keeping the current
OAuthClientProviderfully intact. The implementation is purely additive, and all existing tests pass unchanged.Key Points
- No breaking changes
- Existing
OAuthClientProviderremains unchanged TokenStorageprotocol unchangedOAuthTokenmodel unchanged- Fully backward compatible
- Purely additive implementation
Security
Security posture is unchanged or improved:
- No token logging
- Explicit
Authorization: Bearerinjection - Strict state validation
- PKCE (S256) enforced
- Secrets excluded from repr
Reviewer Focus Areas
I'd especially appreciate feedback on:
async_auth_flow()behavior and retry logic- TokenStorage bridging
- Concurrency safety (
anyio.Lock) - Overall architecture direction for incremental migration
Thanks in advance for taking a look!
cc: @maxisbey @felixweinberger
@pcarleton
Description
Hello,
I would like to validate here before I start the implementation that we want to use Authlib as a Oauth implementation to support more use case in the future and reduce the cost of maintenance of the Oauth stack.
Please can maintainers comment so I don't initiate a long work for nothing.
Thanks a lot !
cc @Kludex @ochafik
References
No response