OAuth 2.1 Server Capabilities for Supabase Auth

[cemalkilic]

📢 UPDATE [September 24, 2025]: Beta applications are now open!

• Apply for beta access here
• ⚠️ Not production-ready - please use a new test project
• 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: Alpha prototype in development Beta testing phase - Apply here

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: jlowin/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!

[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

[aaazzam]

Hey @cemalkilic! I make FastMCP with @jlowin. Would love to collab on this + testing + docs + launch if you're down!

[cemalkilic]

Sure @aaazzam, I already saw you created the PR on the FastMCP side, amazing!! Let's connect & ship 🚢 !

[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?

[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.