OAuth 2.1 Server Capabilities for Supabase Auth

[cemalkilic]

📢 UPDATE [November 26, 2025]: Public beta is live now!

• See the latest comment below for full details

---

Hey Supabase community! 👋

We're excited to share that we're adding OAuth 2.1 server capabilities to Supabase Auth, turning your Supabase project into a full OAuth authorization server. This means your project can act as an identity provider for third-party applications, similar to how you might use "Sign in with Google" today.

Current Status: Public Beta

Target Date:

• Generally available: Q4 2025

What We're Building

We're implementing OAuth 2.1 authorization server capabilities that will allow your Supabase project to:

• Act as an identity provider for third-party applications
• Enable "Login with [Your App]" functionality
• Eventually support OpenID Connect (OIDC) for full SSO capabilities

Exciting Use Cases

MCP (Model Context Protocol) Auth

Use your Supabase project as the auth provider for AI agents and LLM tools that support MCP.

"Login with Supabase Project"

Enable third-party applications to offer "Sign in with [Your App]" - turning your Supabase project into an identity provider like Google or GitHub.

Enterprise SSO (via OIDC - coming next)

Act as a single sign-on provider for your organization's internal tools.

API Access for Partner Integrations

Securely grant scoped access to your API for third-party developers and partners.

How It Works

Here's the authorization flow we're implementing:

sequenceDiagram
    participant User as End User
    participant Client as OAuth Client (Third Party)
    participant Frontend as Developer's Frontend App
    participant Auth as Supabase Auth Backend
    

    User->>Client: 1. Open app / click "Sign in <Supabase Project>"
    Client->>Auth: 2. GET /oauth/authorize?client_id=...&redirect_uri=...
    Auth->>Auth: 3. Create authorization record (no user yet)
    Auth->>Frontend: 4. HTTP 302 redirect with authorization_id
    Frontend->>User: 5. Show login/register page (if not authenticated)
    User->>Frontend: 6. Login/register
    Frontend->>Auth: 7. Authenticate user (pwd, social, MFA, etc.)
    Frontend->>Auth: 8. GET /oauth/authorizations/{authorization_id} (with auth)
    
    alt Auto-approve (existing consent)
        Auth->>Frontend: 9. Return JSON with redirect URL
        Frontend->>Client: 10. HTTP 302 redirect to client
    else Manual consent required
        Auth->>Frontend: 11. Return authorization details JSON
        Frontend->>User: 12. Show consent screen
        User->>Frontend: 13. Approve/deny consent
        Frontend->>Auth: 14. POST /oauth/authorizations/{authorization_id}/consent
        Auth->>Frontend: 15. Return redirect URL JSON
        Frontend->>Client: 16. HTTP 302 redirect to client
    end

Loading

Key Design Decision: Flexible Authorization UI

Traditional OAuth servers host your application's UI. Instead, we're giving you complete control over the authorization and consent screens. After the initial /authorize call the user is taken to your app's frontend to be presented with the consent screen. This provides the freedom to build your app how you want, while Supabase Auth takes care of the protocol specifics:

• Design custom login/registration flows (can use your existing login as it is)
• Implement your own consent screens
• Handle authentication however you prefer (password, social login, MFA, etc.)

This gives you maximum flexibility to match your application's design and user experience.

What Supabase Provides

• OAuth 2.1 Protocol Handling: Full implementation of authorization code flow with PKCE
• Token Management: JWT access tokens and refresh tokens
• Client Registration:
  • Dashboard UI for manual client registration
  • Dynamic client registration API (perfect for MCP auth!)
• Token Validation: JWKS endpoint for third-party token validation, thanks to asymmetric JWTs
• APIs for Authorization Flow: Endpoints to handle approval/denial decisions
• Client Libraries: SDK updates for easy integration (coming soon)
• UI Components: Consent screen components via Supabase ui.supabase.com (planned)

What You Need to Implement

• Authorization/Consent UI: Create your own login and consent screens
• User Authentication Logic: Handle how users prove their identity
• Consent Management: Present scope information (tbd) and capture user approval

Access Token Structure

Access tokens will be JWTs (like current Supabase tokens) with:

• All standard Supabase claims (user_id, role, etc.)
• Additional client_id claim for OAuth client identification
• Compatible with existing Row Level Security(RLS) policies (same role claim structure)

Balancing RLS Power with OAuth Scopes

We want to preserve the power and flexibility of RLS policies while also enabling developers to "scope down" access tokens based on OAuth scopes. This is a challenging balance - RLS gives you fine-grained, row-level control, while OAuth scopes traditionally work at a higher level.

Our current thinking includes exploring these approaches:

1. Custom Access Token Hook: Extend the existing hook system to modify token claims based on OAuth context
2. OAuth-specific Access Token Hook: A new dedicated hook that runs only for OAuth token generation
3. JWT Template System: Define templates that control token structure based on client/scope combinations

Initial Limitations & Future Roadmap

Phase 1:

• Authorization code flow with PKCE
• Refresh tokens
• No scope management initially (tokens have full user privileges, rely on RLS for authorization)

Phase 2:

• OpenID Connect support
• Scope management system & customization of tokens generated by OAuth flows

We Need Your Feedback!

We'd love to hear your thoughts on:

1. Scope Management & Token Customization

Currently, we're starting without a scope system: OAuth tokens will work like regular session tokens with full user privileges. Authorization happens via RLS policies. We're exploring ways to "scope down" OAuth tokens while preserving RLS:

• Would you prefer Custom Access Token Hooks, OAuth-specific hooks, or JWT templates?
• How should OAuth scopes translate to token restrictions?
• Would you need granular scopes immediately or is basic token customization enough to start?

2. OpenID Connect Features

As we plan OIDC support, which features are most critical for you?

• Userinfo endpoint
• ID tokens
• Specific claims in ID tokens
• Session management
• Other OIDC features?

3. Dashboard UI for OAuth Client Management

What would you need in the dashboard?

• Client registration and management
• Consent history and revocation
• Token analytics
• Scope configuration (when available)
• Testing tools?

4. Your Use Cases

What would you build with this? We're especially interested in:

• Use cases we haven't considered
• Integration scenarios with existing systems
• Security or compliance requirements
• Performance or scaling considerations

Questions?

Drop your questions, feedback, and use cases below! We're actively working on this and your input will directly influence the implementation.

[christianfuerst]

Plugin solution for fast-mcp would be really awesome.
https://gofastmcp.com/servers/auth/remote-oauth

[cemalkilic]

We support dynamic client registration & other MCP auth spec requirements so it'll be plug & play!

[jlowin]

@aaazzam implemented a full integration here: PrefectHQ/fastmcp#1997 but I think it has some guesswork because we don't have beta access yet 🙏. Depending on how close you think the beta will end up being to prod, happy to release this (with a beta caveat) once we can affirm it works!

[zenfin-tech]

Any news here?

[cemalkilic]

Big thanks to FastMCP team, SupabaseProvider is available in the fastmcp.
Here’s a minimal MCP server demo using it: https://github.com/cemalkilic/supabase-auth-oauth2-demo/blob/71ce2f456f40813d7fad17ec2db7802024450d1d/apps/taskflow-mcp-server/main.py#L32-L36

[MSMelok]

Golden ❤️

[jeremytenjo]

The Supabase team is awesome!

[mgm1313]

Really cool, we were about to start building this internally, so will be closely following! Out of curiosity, I believe Supabase uses their own auth internally as well. Furthermore there's currently a Supabase OAuth flow for the Integrations part, which is built closed-source. Is it intended to (ultimately) also move this part to the now to be created OAuth capabilities in Supabase Auth? Asking because it would show the ambition of this project, as well as showcase a potential use case already.

[cemalkilic]

Thanks for the comment! We love dogfooding our products whenever possible, but in this case the platform uses opaque access tokens and has some complex RLS policies that wouldn’t translate well to JWTs. Though we’ll keep exploring ways to bring things closer over time.

[otizhi]

So great to see this! Thanks heaps for listening to your community who requested this. It will be a game changer for creating applications that will also present an MCP endpoint. Please create a really good and in-depth tutorial or blog on how to use this. Also, documentation is key to help AI agents implement systems with Supabase. Please keep your documentation complete, detailed, and up to date, especially for something like this.
Thanks for the awesome product and for keeping your software open source. This not only removes long term lock-in concerns but also allows models to be trained against your code-base, leading to better overall quality and integration when using Supabase.

[skvark]

Waiting for this as well, great to have it on the roadmap. I rolled my own API key-based authentication mechanism for https://githits.com in the meantime, but DCR would be a nice UX improvement, making it easier to publish and use the hosted MCP server. Will migrate as soon as this is out.

[koikar]

Is there a opt-in or early access that I should be aware of?

This is critical for users building MCP-first platforms. Excited to give feedback and push the limits

[cemalkilic]

Hi @koikar, thanks for the interest! We plan to give the updates/guidelines on early-access by Wednesday 24th September. Stay tuned!

[zenfin-tech]

Is there a place to opt-in the early access?
I am building a MCP server, any work around for before this release?

[cemalkilic]

Hi @zenfin-tech, thanks for the interest! We plan to give the updates/guidelines on early-access by Wednesday 24th September. Stay tuned!

[masyyy]

Would really appreciate DCR for vihko.ai. Currently using user managed API keys instead.

[cemalkilic]

🚀 Beta Applications Now Open!

Hey everyone! Thanks for all the enthusiasm and feedback! We're ready to start onboarding beta testers for Supabase OAuth 2.1 server capabilities.

📝 Apply for beta access: Click here

🎮 Demo app: Click here

How the beta works:

We'll set up your project with:

• Early update to v2.180.0 (coming to all users very soon!)
• OAuth 2.1 configurations enabled based on your form responses
• Access to test the full OAuth flow

You can also test it locally by using supabase CLI. Make sure you're on a version v2.47.0+ of supabase. You can follow these steps to set up locally until the documentation is in place.

Coming soon:

• Self-serve OAuth Server management in Supabase Dashboard
• Comprehensive documentation

⚠️ Important: Not for production yet!

This is a beta feature - we strongly recommend creating a new Supabase project for testing rather than using your production project. This lets you experiment safely while we refine the implementation.

What's next:

1. Fill out the beta application form with your OAuth configuration needs
2. We'll manually enable the features for your project
3. Start building and share your feedback!
4. Detailed docs will follow shortly

The feedback from beta testers will directly shape the final implementation before general availability.

---

Questions about the beta? Drop them below

[zenfin-tech]

@aaazzam can you share the link to the open issue on the FastMCP side?

[zenfin-tech]

@cemalkilic any news here? Thanks

[cemalkilic]

Hi @zenfin-tech, I replied back to all beta requests. Have you received an email from me about enabling it?

[joaoalvarenga]

I am testing the feature locally to build ChatGPT apps and have applied for the beta. Do we already have any perspective for GA?

[cemalkilic]

Hey @joaoalvarenga, we're in public beta now, check the latest message here!

[nietsmmar]

Will there also be generic OIDC provider coming with this update? (see: https://github.com/orgs/supabase/discussions/6547)

[cemalkilic]

Hi @nietsmmar, this update is about Supabase Auth becoming an OAuth 2.1 / OIDC provider, so your project can issue tokens to external clients.

The “generic OIDC provider” in #6547 is the opposite, that’s about Supabase Auth acting as a client to external providers. We’re planning to make that setup more generic, so it won’t need custom work for each provider in the future.

[nietsmmar]

Yes. I just thought that if there is such a major update to the whole auth thing that this might be something that is done at the same time as there hasn't been any information when this will be done besides that it is on the roadmap.

[skvark]

Is there a way for users to view and revoke authorized OAuth 2.1 clients? I'm looking at this from the MCP + DCR perspective.

I think this should be part of the OAuth 2.1 server, as users need to see which apps they’ve authorized and revoke access if required.

[cemalkilic]

You're absolutely right, users need to be able to see what they've authorized and revoke access when needed. This is especially important for MCP scenarios where people might end up authorizing multiple agents.
We're actually working on this right now: supabase/auth#2232
Thanks for the feedback!

[skvark]

Awesome, thanks!

[henritoivar]

I applied for beta access and until I'm waiting to get approved it would be nice to be able to configure the oauth server locally to use my ngrok tunnel url. I think a lot of people will be using a tunnel to expose their local development environment to test if their service works with a third-party before deploying it.

To do this we need to change the base url for the auth server locally. Right now /.well-known/oauth-authorization-server has the urls referencing localhost even when using a tunnel. Which is used for discovery by third-party services. Being able to change the base url via config.toml would be very beneficial to the development work flow.

The other option is running the self-hosted supabase instance locally, but it's much more cybersome.

[aantti]

I'd second this :) I was experimenting recently with self-hosted and the new oauth, and the fact baseUrl and redirectUrl are always built from SITE_URL was a bit inconvenient, @cemalkilic

https://github.com/supabase/auth/blob/9a8d0df63bb5089e1705f9d970669bfc97ed345e/internal/api/oauthserver/authorize.go#L165

It would be nice to have more flexibility here and not tying it up to SITE_URL.

[cemalkilic]

Thanks for the detailed feedback, both of you!
So there are two different things here:

1. The SITE_URL for redirect URIs
   This is actually a design decision we're keeping for now. We intentionally tie the base URL and redirect URL to SITE_URL for security reasons - it prevents redirecting to arbitrary locations. I know it's less flexible, but it helps keep things secure out of the box.
2. The issuer in discovery metadata
   This is the one we can help with! The /.well-known/oauth-authorization-server endpoint currently uses the issuer config value (which is set as the local instance URL by the cli tool) which breaks discovery when you're using a tunnel.
   We can expose an issuer config option in config.toml so the discovery metadata reflects your tunnel URL properly. Would that solve the discovery issue for your local development workflow?

Thanks for explaining the problem so clearly - really helpful feedback!

[henritoivar]

Regarding 2. - Yes it should work perfectly, thank you!

[cemalkilic]

FYI, customizing jwt_issuer config in CLI is implemented here: supabase/cli#4388

[dishwad]

This is awesome! This would make it much easier to support exposing our app's API with various scopes.

Eventually support OpenID Connect (OIDC) for full SSO capabilities

If the plan is to eventually support OIDC as part of this work on the roadmap, does this mean that you'll also be adding support for integrating our Supabase project with other IdP providers using OIDC? Right now for SSO with projects only SAML is supported.

Some other aspects of SSO that I think could really use some love:

• Support SSO in Supabase local development. This would make it much easier for testing. Related issue here.
• Expose the SSO endpoints that are used by Supabase CLI for managing connections in the dashboard. Managing this in the Supabase dashboard would be really nice.

[cemalkilic]

🚀 UPDATE: Public Beta is Now Live!

OAuth Server support in Supabase Auth is now available in public beta.
You can now find all configuration options directly in your project dashboard, and full documentation is published:

Docs: https://supabase.com/docs/guides/auth/oauth-server

---

What this enables

Your Supabase project can now act as an OAuth/OIDC Provider, essentially a “Sign In with YourApp” identity provider for other apps, services, or integrations.

---

Demo Repository

To help you get started quickly, I’ve published a small end-to-end example:

🔗 Demo repo: https://github.com/cemalkilic/supabase-auth-oauth2-demo

The repo includes:

• Taskflow: a Supabase project acting as the OAuth server
• FocusTime: a client app authenticating against Taskflow and fetching user info
• MCP example: shows how a fastmcp MCP server can authenticate using Supabase Auth

Feel free to explore it!

---

Feedback Welcome 🙏

Would love to hear from you:

• What flows are you planning to build with this?
• Anything unclear in the dashboard, docs, or behavior?
• Any issues you ran into while testing?

Your feedback here will directly help shape the stable release. Thanks for trying it out! 🎉

[jasonforte]

Hi, thanks for working on this, I think it'll be a huge value add for customers!

I'm testing out a connection between AWS and Supabase. I'm aiming to connect the OAuth server as an identity provider in AWS IAM so that Supabase JWTs can be used to authenticate with AWS services.

When trying to authenticate against IAM using , I'm getting an error: "The amr claim is neither a string nor a list of strings".

aws sts assume-role-with-web-identity --role-arn arn:aws:iam::<account>:role/service-role/SupabasePermissions --role-session-name supabase-sample-role --web-identity-token '<JWT_TOKEN>'

An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: The amr claim is neither a string nor a list of strings

RFC is a bit ambiguous, would appreciate any guidance.

[cemalkilic]

Hi @jasonforte, thanks for testing this out and for the detailed feedback, super helpful!

You’re right about the error: Supabase Auth currently encodes amr as an array of objects (e.g. [{"method": "password", "timestamp": 1715686621}]), whereas AWS STS expects amr to be either a string or an array of strings, per RFC 8176.

We don’t have immediate plans to change the default amr format, so the best workaround today is to normalize the claim using a Custom Access Token Hook so the final JWT matches what AWS expects.

If you get a chance to test this and share your results, that would be greatly appreciated!

[jasonforte]

Hi, I've tested with both the HTTP and the database hooks. I get the following error coming through:

output claims do not conform to the expected schema: - amr.0: Invalid type. Expected: object, given: string

Looks like the schema is being validated as a list of objects after the hook returns.
https://github.com/supabase/auth/blob/c6b8caa6cb24a43223c6f5c7cbe33af33ec59abd/internal/tokens/service.go#L951

[cemalkilic]

Sorry about that! Loosening the validation here: supabase/auth#2274

[IntranetFactory]

I have a problem with the consent handling.

await supabase.auth.oauth.getAuthorizationDetails(authorizationId) works and returns

but the next await supabase.auth.oauth.approveAuthorization(authorizationId) always fails with

{
    "code": "validation_failed",
    "message": "authorization request cannot be processed"
}

I do not see any usable information in the log

What could be the issue? Should I report that problem somewhere else?

[IntranetFactory]

Found the reason for my problem. Our client added default oidc openid profile email scopes to /oauth/authorize The authorize endpoint did not complain, but getAuthorizationDetails then fails with that unspecific error message.

It seems that the code on https://supabase.com/docs/guides/auth/oauth-server/getting-started?queryGroups=oauth-setup&oauth-setup=dashboard&queryGroups=framework&framework=react does not include that the response could contain a redirect_url which then must immediately redirect !

[cemalkilic]

Sorry for the inconvenience! For future reference, this has been resolved in supabase/supabase-js#2088

[Franklyn-R-Silva]

Great update! I'm really looking forward to seeing how the balance between RLS and OAuth Scopes will be implemented. In my experience with ERP systems, granularity is key. I would vote for the OAuth-specific Access Token Hooks approach. This would allow mobile developers (especially in Flutter) to ensure that third-party apps only have the necessary access without compromising existing RLS policies in the database.

[jejrthompson]

Just a quick note... custom domains do not flow through to the /.well-known/oauth-authorization-server/auth/v1 endpoint. I'm not an OAuth expert but I'm noticing clients are having trouble discovering metadata if I use the custom domain as the host vs. the standard Supabase domain. Really excited to use this feature though and stop rolling my own OAuth and associated tables.

[cemalkilic]

Thanks for the feedback! I'll take this and discuss internally and get back to you in this thread.

[lhphong1409]

A small update after using OAuth 2.1 on my product,

1. Is the redirect_uri must include http and https schema, because my desktop. android, and ios app need to convert from deeplink to universal link for matching with this setup
2. Idk but the create 3rd client via api only accept confidential client, I can not setup with public client now
3. Seem that I can not find the revoke feature with third party access token, mean user want to logout from third party app

[lhphong1409]

Hi @lhphong1409, apologies for the delay here.

1. It's fixed with fix(oauth-server): allow custom URI schemes in client redirect URIs auth#2298. If you're using the hosted supabase project, this should already work. If you self host, please make sure auth server version is >2.186.0.
2. Can you let me know how you try to create the public client and what doesn't work?
3. revokeGrant should do the job, docs

Thank for replies,

1. I set up with Supabase cloud, I will test this one again and let you know
2. Like the comment of Gbuomprisco bellow, I use replace confidential with public in this example and error happen

// Create an OAuth client
const { data, error } = await supabase.auth.admin.oauth.createClient({
  name: 'My Third-Party App',
  redirect_uris: ['https://my-app.com/auth/callback', 'https://my-app.com/auth/silent-callback'],
  client_type: 'confidential',
})

3. current revokeGrant mean user revoke manually from consent/auth site, I confused about "how 3rd party revoke/logout user from their app`

[lhphong1409]

Hi @cemalkilic, we have a critical issue with Supabase Oauth 2.1. All of my confidential client can not process login with <my app> in their 3rd party app, seem that confidential client was not accepted anymore.

I use this endpoint in 3rd app and get this issue

curl -X POST 'https://<project-ref>.supabase.co/auth/v1/oauth/token' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=authorization_code' \
  -d 'code=<authorization-code>' \
  -d 'client_id=<client-id>' \
  -d 'client_secret=<client-secret>' \
  -d 'redirect_uri=<redirect-uri>' \
  -d 'code_verifier=<code-verifier>'

{
    "code": 400,
    "error_code": "invalid_credentials",
    "msg": "invalid authentication method: client is registered for 'client_secret_basic' but 'client_secret_post' was used"
}

Ref: OAuth 2.1 Flows

[cemalkilic]

Hi @lhphong1409 , apologies for the issue!

As you provide the client credentials in the POST body, the token_endpoint_auth_method must be client_secret_post. You can update the existing confidential clients by the following query (assuming all of them uses POST body) in the dashboard SQL editor:

UPDATE auth.oauth_clients SET "token_endpoint_auth_method" = 'client_secret_post' WHERE "token_endpoint_auth_method" = 'client_secret_basic'

I'll extend the examples in the docs and explain this case. Sorry for the issue again!

Did you create these clients through Supabase Dashboard or direct API calls (POST /auth/v1/admin/oauth/clients) by yourself?

[lhphong1409]

Thank @cemalkilic for the reply, I create via direct API calls in my app with this

    const { data: clientData, error } = await supabase.auth.admin.oauth
      .createClient({
        client_name: input.name,
        redirect_uris: input.redirectUris ??
          ["http://localhost:3000/api/v1/auth/callback"],
      });

---

Updated
Idk if this is the good way to solve this issue

   const response = await fetch(
      `${env.SUPABASE_URL}/auth/v1/admin/oauth/clients`,
      {
        method: "POST",
        headers: {
          "Authorization": `Bearer ${env.SUPABASE_SECRET_KEY}`,
          "apikey": env.SUPABASE_SECRET_KEY,
          "Content-Type": "application/json",
        },
        body: JSON.stringify({
          client_name: input.name,
          redirect_uris: input.redirectUris ??
            ["http://localhost:3000/api/v1/auth/callback"],
          client_type: input.clientType ?? "confidential",
          token_endpoint_auth_method: input.clientType === "confidential"
            ? "client_secret_post"
            : "none",
        }),
      },
    );

[cemalkilic]

If it's confidential client and they're using POST body, the token endpoint auth method must be client_secret_post. There is a small bug in the code snippet you shared: token_endpoint_auth_method checks input.clientType directly, but it can be null, so it always falls through to "none" even though client_type defaults to "confidential". Fix:

token_endpoint_auth_method: (input.clientType ?? "confidential") === "confidential"
  ? "client_secret_post"
  : "none",

Meanwhile, I updated the supabase-js sdk to support this param. I just merged the change, it'll be available in the next release. So you can use the library again with the support of token_endpoint_auth_method 🙏

[Gbuomprisco]

I also could not find a way to create a public client; the API described here in the JS section must be an AI hallucination because they're 100% wrong

[cemalkilic]

Hi @Gbuomprisco, I just tried the code snippet in that example and it worked fine. Can you please share the error or tell me what's wrong?

[alita-moore]

Hey, great work on this. I have a two-project setup where my core Supabase project is the identity provider and a separate website project uses anonymous auth for visitors. When users eventually sign up I want them to authenticate against the core project and then link that identity back to their anonymous user on the website project.

The OAuth 2.1 server handles the provider side but the gap is that my website project can't consume a custom OIDC provider natively since Supabase Auth only supports specific social providers. I also need the website to be able to query the core project for things like billing info using the authenticated session, and ideally have sessions stay in sync across both projects.

Is there any plan to support consuming another Supabase project as an OIDC provider, or to open up the third-party auth feature to arbitrary OIDC issuers beyond the current five? That would make multi-project setups like this much more straightforward. Thanks.

[cemalkilic]

Hi @alita-moore thanks for the feedback and explaining the use case!
Indeed, we're currently working on support custom OIDC & OAuth providers where you can add arbitrary OIDC providers (including another Supabase project) in the dashboard. The plan is to roll it out by end of this month.

[lauri865]

We have set our SITE_URL to our backend api, because we want all auth requests to pass through our backend for various reasons, primarily because we have a multi-tenant APP with multiple frontends / subdomains, so there's no single SITE_URL. Hence we need backend to be in charge for redirects, etc.

We can of course centralise oauth consent screen to a single domain, but using SITE_URL for that is limiting. Hence, it would be create to be able to customize it for the OAuth server rather than relying on the global SITE_URL.

Otherwise things like supabase.auth.oauth.getAuthorizationDetails cannot be used on the client side (mismatching origin/referer). We have found a hacky workaround by doing these calls on the server by passing referer and origin headers to supabase.auth.oauth.getAuthorizationDetails, but we need to be cautious by first validating the original referer/origin in order not to introduce any security issues in the flow. Hence it's a hack.

[cemalkilic]

Thanks for the detailed explanation @lauri865 !

Right now the OAuth flow is designed around a single canonical site, defined by SITE_URL. We use that as the security anchor for redirects and for validating things like origin and referer, which is why helpers like supabase.auth.oauth.getAuthorizationDetails expect requests to come from that domain.

Setups with multiple frontend domains (like multi-tenant apps) don’t fit this model perfectly. Routing the OAuth flow through your backend, like you're doing, is a reasonable workaround, but it’s not something the current design explicitly supports.

Improving this (for example by decoupling OAuth url validation from SITE_URL or allowing more flexible origins alongside the redirect URLs) is something we could explore in the future, but it would require broader changes to the current auth flow.

Really appreciate you sharing the details of your setup, it's helpful feedback for us.

[lauri865]

I mean, we could easily host the oauth flow centrally on oauth.domain.tld (or just domain.tld), but it's still not gonna be our SITE_URL. Absolutely don't need to support multi-domain oauth flows.

[spjoes]

Hello! I see that granular/custom scopes are on the roadmap. Any eta on this? Would love to start tinkering around with it. Thanks in advance and keep up the good work!

[cemalkilic]

Thanks for the interest!

Granular/custom scopes are on the roadmap, but we unfortunately can't provide an ETA at the moment. We'll share updates once we start making progress on it.

[nujhong]

I’ve been able to set up a Figma-style mobile OAuth flow using ASWebAuthenticationSession, and also use it for MCP auth with a Supabase OAuth server 🙌 I had two questions:

• Is support for Device Authorization Grant on the roadmap?
  • related MCP discussion: [Proposal] Non-Interactive OAuth Flows for Headless & Limited-Input MCP Clients modelcontextprotocol/modelcontextprotocol#298)
• Is RP-Initiated Logout in scope, or what’s the recommended way to handle OAuth client logout / grant revocation?
  • The reason I’m asking about logout is that supabase.auth.signOut() supports local / others / global, but what I need here is effectively “log out this requesting client and revoke the corresponding grant”. Right now, revoking from the same requesting session returns 204 but doesn’t seem to invalidate the effective OAuth session/grant, so the only workaround I’ve found is revoking it server-side by impersonating the user session, since there's also currently no api to support this operation yet with supabase.auth.admin.oauth

[cjxe]

Hi @cemalkilic - thank you for developing this feature, we started using it.

Anything unclear...?

Currently, scope's type is string in supabase-js. I expected it to be strongly typed like Array<Scope> so my scope handler can handle each scope. E.g.,

function getScopeDisplayDetails(scope: string): ScopeDisplayDetails {
  switch (scope) {
    case "openid":
      return {
        description: "Verify your identity and sign you in with your A account.",
        icon: byPrefixAndName.fal["shield-keyhole"],
      };
    case "profile":
      return {
        description: "View your basic profile information.",
        icon: byPrefixAndName.fal["user"],
      };
    case "email":
      return {
        description: "View your email address.",
        icon: byPrefixAndName.fal["envelope"],
      };
    default:
      return {
        description: `Access the ${scope} permission.`,
        icon: byPrefixAndName.fal["circle-question"],
      };
  }
}

But right now, I am at the mercy of Supabase.

Any issues you ran into while testing?

1. When I upload a logo (as small as 250px x 250px 3kb in png or jpg format), then the server returns an error:

Failed to update OAuth Server application: logo_uri cannot exceed 2048 characters

So, what are the oauth logo limits?

  /**
   * ...
   * This method returns one of two response types:
   * - `OAuthAuthorizationDetails`: User needs to consent - show consent page with client info
   * - `OAuthRedirect`: User already consented - redirect immediately to the OAuth client
   * ...
   */
  getAuthorizationDetails(authorizationId: string): Promise<AuthOAuthAuthorizationDetailsResponse>

This response flow doesn't make sense, I expected this to be handled at the browser that receives this response. Because I might need to show the OAuthAuthorizationDetails even if the user consented before.

What flows are you planning to build with this?

I have an app. I created a Discord server for my users to reach out to me by creating support tickets. The biggest friction was asking for the ticket creator's username, waiting, and then verifying. To improve the process, if the ticket creator hasn't linked their Discord to my app's username, my custom Discord App/Bot asks the ticket creator to log into my Discord App/Bot with my app (which then sets the user's Discord ID in that user's profile table).

[mindhells]

Hi,
Based on the original announcement, this feature was targeted for GA in Q4 2025. We've been evaluating the Supabase OAuth server as a core part of our authentication strategy and were hoping it would be stable by now. A few questions as we plan our adoption:

• GA timeline — Is there a revised target date? The Q4 2025 deadline has passed without an update.
• Breaking changes — Should we expect any between the current public beta and GA? We want to plan our migration accordingly.
• Pricing — Will this feature be available across all tiers, including Pro? Are there any additional costs tied to MAU?

For context, our intended setup is: a dedicated authorization server acting as the OAuth 2.1 provider, with our web and mobile applications as OAuth clients. We're not looking for granular scope management in Phase 1 — standard PKCE flows with client_id binding are sufficient for our use case.

Thanks a lot!

[dinodeSimon]

OIDC Discovery Issuer Mismatch When Using Custom Domains

We're using the OAuth 2.1 server capabilities to enable SSO between two Supabase projects — one acts as the identity provider (IdP) and the other as the relying party (RP). This works perfectly when using the default .supabase.co URLs, but breaks when the IdP project has a custom domain configured.

Setup:

• Project A (IdP): has a custom domain api.example.com pointing to project ref abcdefghijklmnop
• Project B (RP): registers custom:myapp provider via the admin API

Repro steps:

1. Create an OAuth app on Project A (the IdP) via dynamic client registration:

   POST https://api.example.com/auth/v1/oauth/clients/register
   

2. Register a custom OIDC provider on Project B (the RP):

   POST https://<project-b-ref>.supabase.co/auth/v1/admin/custom-providers
   {
     "identifier": "custom:myapp",
     "provider_type": "oidc",
     "name": "My App",
     "client_id": "<from step 1>",
     "client_secret": "<from step 1>",
     "issuer": "https://api.example.com/auth/v1",
     "pkce_enabled": true,
     "enabled": true,
     "scopes": ["openid", "email", "profile"]
   }
   

3. Step 2 fails with:

   {
     "code": 400,
     "error_code": "validation_failed",
     "msg": "OIDC discovery issuer mismatch: discovery document reports \"https://abcdefghijklmnop.supabase.co/auth/v1\" but expected \"https://api.example.com/auth/v1\""
   }

Root cause: The OIDC discovery document at https://api.example.com/auth/v1/.well-known/openid-configuration returns the canonical .supabase.co URL as the issuer field, not the custom domain the request was made through. When GoTrue validates the provider registration, it correctly enforces RFC 8414 §3.3 (issuer must exactly match the discovery URL), but the discovery document itself doesn't respect the custom domain.

Workaround: Use the .supabase.co URL as the issuer instead of the custom domain. This works but defeats the purpose of having a custom domain and leaks the project ref.

Expected behavior: The discovery document should return the custom domain as the issuer when accessed via a custom domain, so the issuer validation passes naturally.

[dinodeSimon]

To add some context — the root cause is in internal/api/jwks.go in the WellKnownOpenID handler:

response := OpenIDConfigurationResponse{
    Issuer:                config.JWT.Issuer,
    AuthorizationEndpoint: issuer + "/oauth/authorize",
    ...
}

The issuer is always config.JWT.Issuer — a static value from GOTRUE_JWT_ISSUER, set at startup by the platform to https://<ref>.supabase.co/auth/v1. The request's Host header is never consulted, so custom domains have no effect on the discovery document.

This also means all issued JWTs (iss claim) use the canonical URL regardless of custom domain — see internal/tokens/service.go line 691 for access tokens and line 776 for OIDC ID tokens.

Since GOTRUE_JWT_ISSUER isn't exposed in the dashboard or Management API for hosted projects, there's no workaround on the user side for the discovery mismatch — you have to know the project ref and use the .supabase.co URL as the issuer when registering custom OIDC providers.

[addniner]

We are seeing the same need while evaluating Supabase OAuth 2.1 Server as a central OAuth/OIDC provider for multiple service apps.

Spring Security OAuth2 Login / OIDC works for login, but the discovery document does not expose end_session_endpoint, so OidcClientInitiatedLogoutSuccessHandler cannot be used.

For now, we need an auth-frontend-managed logout endpoint that calls supabase.auth.signOut() and redirects back to the service app.

This seems aligned with the enterprise SSO / OIDC provider use case. Is RP-Initiated Logout planned for the OAuth 2.1 Server roadmap?

[lopezjurip]

Is there any plans or progress to support custom scopes per project?