Tags: supabase/auth
Tags
feat: log sb-auth-user-id, sb-auth-session-id, ... on sign in not jus… …t refresh token (#2342) In #2216 some new headers were added to responses that are able to track the user ID, session and other data which cannot be extracted from JWTs. This aids in debugging and correlation of all requests made by a specific user.
feat(oauth-server): store and enforce token_endpoint_auth_method (#2300) ## Problem I noticed there was a TODO for storing the `token_endpoint_auth_method` value. While integrating with Claude.ai's OAuth flow, we discovered that returning `client_secret_basic` for all clients (regardless of their actual registration) was breaking the authentication flow. Claude.ai strictly validates the auth method returned during client registration, so it was critical for us to return the correct value. Per [RFC 7591 Section 2](https://datatracker.ietf.org/doc/html/rfc7591#section-2): > If unspecified or omitted, the default is "client_secret_basic" For public clients, the default is `none` since they don't have a client secret. ## Solution Added proper storage and enforcement of `token_endpoint_auth_method`: ### Database Changes - Added `token_endpoint_auth_method` TEXT column (NOT NULL) to `oauth_clients` table - Migration sets default values for existing clients based on their `client_type`: - `confidential` → `client_secret_basic` - `public` → `none` ### Behavior - New clients get `token_endpoint_auth_method` persisted during registration - Token endpoint validates that the authentication method used matches the registered method - Returns the correct `token_endpoint_auth_method` in client registration responses --------- Signed-off-by: Pierre Dulac <[email protected]> Signed-off-by: Pierre Dulac <[email protected]> Co-authored-by: Cemal Kılıç <[email protected]>
feat: add Supabase Auth identifier to OAuth redirect URLs (#2299) ## Summary Adds a Supabase Auth identifier (`sb`) to URL fragments in all OAuth redirect responses to help clients distinguish Supabase Auth redirects from third-party OAuth flows. ## Problem auth-js GoTrueClient currently intercepts all URL fragments containing `access_token`, including those from non-Supabase OAuth providers. This causes unintended logouts and authentication issues when users have other OAuth flows in their applications. Related issue: supabase/supabase-js#1697 ## Solution Added an empty `sb` parameter to the URL fragment in all redirect responses: - Success redirects with tokens (via `AsRedirectURL`) - Error redirects in OAuth callbacks ([supabase-js has](https://github.com/supabase/supabase-js/blob/a66387e9923255160031a1c55545cf7ab27b3aaf/packages/core/auth-js/src/lib/errors.ts#L14-L38) a `__isAuthError`, but adding it for error to be fault-tolerant, and non-supabase-sdk cases) - Error redirects in verification flows - Message redirects in verification flows Example redirect URL: `https://example.com/callback#access_token=xxx&refresh_token=yyy&expires_in=3600&sb` Clients can now check for the presence of `sb` in the fragment to confirm the redirect originated from Supabase Auth.
chore(master): release 2.185.0 (#2287) 🤖 I have created a release *beep* *boop* --- ## [2.185.0](v2.184.0...v2.185.0) (2026-01-12) ### Features * Add Sb-Forwarded-For header and IP-based rate limiting ([#2295](#2295)) ([e8f679b](e8f679b)) * allow amr claim to be array of strings or objects ([#2274](#2274)) ([607da43](607da43)) * reset main branch to 2.185.0 ([#2325](#2325)) ([b9d0500](b9d0500)) * Treat rate limit header value as comma-separated list ([#2282](#2282)) ([5f2e279](5f2e279)) ### Bug Fixes * additional provider and issuer checks ([#2326](#2326)) ([cb79a74](cb79a74)) * check each type independently ([#2290](#2290)) ([d9de0af](d9de0af)) * fix the wrong error return value ([#1950](#1950)) ([e2dfb5d](e2dfb5d)) * **indexworker:** remove pg_trgm extension ([#2301](#2301)) ([c553b10](c553b10)) * **oauth-server:** allow custom URI schemes in client redirect URIs ([#2298](#2298)) ([ea72f57](ea72f57)) * tighten email validation rules ([#2304](#2304)) ([33bb372](33bb372)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
feat: reset main branch to 2.185.0 (#2325) Resets the main branch (`master`) to have the same changeset as 2.184.0 but under 2.185.0. Original release please notes: ### Features * Add Sb-Forwarded-For header and IP-based rate limiting ([#2295](#2295)) ([e8f679b](e8f679b)) * allow amr claim to be array of strings or objects ([#2274](#2274)) ([607da43](607da43)) * Treat rate limit header value as comma-separated list ([#2282](#2282)) ([5f2e279](5f2e279)) ### Bug Fixes * check each type independently ([#2290](#2290)) ([d9de0af](d9de0af)) * fix the wrong error return value ([#1950](#1950)) ([e2dfb5d](e2dfb5d)) * **indexworker:** remove pg_trgm extension ([#2301](#2301)) ([c553b10](c553b10)) * **oauth-server:** allow custom URI schemes in client redirect URIs ([#2298](#2298)) ([ea72f57](ea72f57)) * tighten email validation rules ([#2304](#2304)) ([33bb372](33bb372)) --------- Co-authored-by: depthfirst-app[bot] <184448029+depthfirst-app[bot]@users.noreply.github.com>
fix(oauth-server): allow custom URI schemes in client redirect URIs (#… …2298) ## Problem Fixes #2285 The OAuth 2.0 Client Registration endpoin was incorrectly rejecting custom URI schemes like `cursor://`, or `myapp://`, blocking native application integrations. ## Root Cause The validation logic in `validateRedirectURI()` was overly restrictive, only allowing HTTPS or HTTP (localhost). This contradicted with **RFC 8252** (OAuth 2.0 for Native Apps) - recommends custom URI schemes ## Solution Relaxed redirect URI validation ### New Validation Rules - **HTTPS** - always allowed - **Custom URI schemes** - allowed for native apps (`cursor://`, `myapp://`, `vscode://`, etc.) - **HTTP** - only for localhost/loopback (`localhost`, `127.0.0.1`, `::1`) - **Fragments** - still rejected per spec
PreviousNext