OAuth 2.1 — Plan and Tracking

<!-- Cache semantics: ensure never_cache is used (no manual headers) --> Note on cache semantics (clarification): - Ensure endpoints use Django's `never_cache` for non-cacheable responses. Most of our OAuth views already do (e.g., `/oauth/authorize` via `AuthLoginView` and `/oauth/token` directly). Confirm `/oauth/userinfo` as well. - Do not add manual `Cache-Control` or `Pragma` headers in these flows; `Pragma` is deprecated. # OAuth 2.1 Migration — Plan and Tracking ## Summary Modernize Sentry's OAuth implementation to comply with OAuth 2.1 specifications and security best practices. This includes PKCE enforcement, strict redirect URI validation, refresh token rotation, proper error handling, and discovery endpoints. ## Goals - Align with OAuth 2.1 draft specification - Improve security through PKCE, strict redirect validation, and token rotation - Add OAuth 2.0 Authorization Server Metadata discovery (RFC 8414) - ~~Support Dynamic Client Registration (RFC 7591/7592)~~ - Support CIMD ([RFC](datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document)) - This is now the recommended way for MCPs: [auth0.com/blog/cimd-vs-dcr-mcp-registration](auth0.com/blog/cimd-vs-dcr-mcp-registration) - Maintain backward compatibility during transition ## Technical Requirements ### OAuth 2.1 Core Requirements - Remove implicit grant flow (or feature flag to disable) - Require PKCE for authorization code flow - Enforce exact redirect URI matching (no prefix matching) - Implement refresh token rotation with reuse detection - Support `client_secret_basic` authentication method - Add proper error responses per RFC 6749 ### Discovery & Metadata (RFC 8414) - `/.well-known/oauth-authorization-server` endpoint - Expose supported grant types, response types, and PKCE methods - Optional OIDC discovery if ID tokens are supported ### Security Requirements - HTTPS enforcement (except loopback for native apps per RFC 8252) - One-time authorization code usage - Token family revocation…