Repository navigation
Extract OAuth flow logic into reusable components for proxy use cases #1743
Description
Summary
Refactor OAuth implementation so the flow logic and state machine are usable by server-side proxy services, not just client-side browser flows.
Problem
The SDK's OAuth implementation is designed for local client-side flows (opening a browser locally). The business logic is embedded inside an httpx auth module, making it hard to reuse for other scenarios.
While individual helper functions have been extracted (PKCE utilities, token exchange, discovery), the core state machine that orchestrates the OAuth flow is not reusable. Proxy services that need to perform OAuth on behalf of users currently have to reimplement significant portions of the flow themselves — and when the SDK updates its OAuth logic, those reimplementations can fall out of sync.
Goal
- Make the OAuth portions of the SDK compatible with proxy/gateway services that currently use custom workarounds
- When an issue is fixed in the SDK, updating the SDK version should fix it everywhere — no custom OAuth reimplementations needed
- Keep existing client-side flows working
Design Requirements (from maintainer discussion, Feb 2026)
Modularization into zones: Break the monolithic OAuth flow into modular, overridable pieces:
- Discovery — obtaining and potentially customizing discovery URLs
- Client Registration — dynamic client registration
- Interactive Flow — authorization URL generation, redirect handling
- Token Fetching — code exchange, refresh, new token extensions (XA, WIF)
- Token Storage — pluggable storage (already exists)
Key requirements:
- Each zone should operate as a pure function requiring minimal state
- Every HTTP request in the flow must be interceptable — allow injection of a custom HTTP client/fetch interface (httpx client in Python, fetch in TypeScript) for custom headers, metrics, response handling
- Support an "Auth Required" state as an SDK primitive — when a server responds with 401/403 mid-flow, the SDK should capture discovery metadata, scope, and WWW-Authenticate info and surface it so the calling application can handle it (rather than assuming auth happens upfront)
- The flow must be resumable — a caller should be able to pick up an auth flow at any point (e.g., after a redirect returns on a different machine/request)
- Support bypassing discovery when configuration is provided directly (important for enterprise environments with broken discovery)
- Support new token-getting extensions (XA, WIF) that don't require interactive flows
Next steps:
- Draft code sketches (potentially TypeScript first) to validate the modular function approach
- Cross-SDK coordination — this applies to both Python and TypeScript SDKs
Related
- Implement OAuth relying on Authlib #1240 - Implement OAuth relying on Authlib
- Replace Field(description=...) with proper docstrings in auth models #2053 - Replace Field(description=...) with docstrings in auth models
Activity
maxisbey commentedon Dec 8, 2025
I was playing around with some ideas this morning with Claude and got this draft which has some interesting ideas for this. Although if there's a more common method of doing this (maybe authlib linked above? haven't looked into it yet) then we should do that.
Here's what Claude wrote:
Code
maxisbey commentedon Dec 8, 2025
Note: This issue now consolidates #1724 (Support for synchronous auth flow with separate re-entry). The action/effect state machine pattern proposed here directly enables the synchronous re-entry use case requested by the Google ADK team - the "awaiting user auth" phase naturally supports pausing and resuming the flow with an authorization code.
jake-mayer commentedon Dec 12, 2025
Thanks for putting this together Max. I read through the code quickly and may be misunderstanding, but it appears to create a state machine internally within a single auth flow rather than allowing for state machine behavior between separate invocations of the auth flow.
Here's some pseudo-code of how I was imagining this would look. Very high-level, but let me know what you think.
New state machine provider
Generic usage example
Re-implementation of existing async provider to use state machine provider
ryanschulz46 commentedon Dec 16, 2025
@jake-mayer - I like your proposed solution - having a way to async continue the auth flow would be helpful.
For reference, this would be helpful for me as my MCP client is being hosted on a serverless architecture (invoked by an endpoint); the auth flow would need to be split in two separate flows (each on different endpoints)
FlowA: Discovery, storing of state, returning auth_url
FlowB: handle callback, fetch state, store tokens
maxisbey commentedon Dec 17, 2025
Yea fully agree with the above! We definitely want the process to be resumable at any point by a different machine if needed. This is a requirement for v2.
jake-mayer commentedon Dec 18, 2025
Thanks Max. Do we have an idea of when v2 will be out? We'd be happy to contrib this from the Google side earlier if that seems reasonable to you.
maxisbey commentedon Jan 5, 2026
Current estimate is Q1, but it's a bit uncertain as I'm currently thinking we wait until the big upcoming changes around transport in the next spec release are finalised. They're going to be significant not just in the protocol but also the SDK, so IMO makes sense to wait for that till we officially release it.
For now we'll be doing releases of v2 of the SDK in prerelease, but each version will almost definitely have breaking changes.
maxisbey commentedon Feb 19, 2026
Related: #1240 proposes using Authlib as the OAuth implementation, which could be relevant as an implementation approach for this rework. cc @pcarleton
yannj-fr commentedon Apr 30, 2026
@maxisbey is the authlib rework you mentioned something that still help? I can get back working on it again