OAuth 2.1 Server Capabilities for Supabase Auth #38022
Replies: 13 comments 21 replies
-
|
Plugin solution for fast-mcp would be really awesome. |
Beta Was this translation helpful? Give feedback.
-
|
The Supabase team is awesome! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Is there a place to opt-in the early access? |
Beta Was this translation helpful? Give feedback.
-
|
Would really appreciate DCR for vihko.ai. Currently using user managed API keys instead. |
Beta Was this translation helpful? Give feedback.
-
🚀 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 hereHow the beta works:We'll set up your project with:
You can also test it locally by using Coming soon:
|
Beta Was this translation helpful? Give feedback.
-
|
Will there also be generic OIDC provider coming with this update? (see: https://github.com/orgs/supabase/discussions/6547) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
This is awesome! This would make it much easier to support exposing our app's API with various scopes.
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:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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 developmentBeta testing phase - Apply hereTarget Date:
What We're Building
We're implementing OAuth 2.1 authorization server capabilities that will allow your Supabase project to:
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 endKey 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
/authorizecall 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:This gives you maximum flexibility to match your application's design and user experience.
What Supabase Provides
What You Need to Implement
Access Token Structure
Access tokens will be JWTs (like current Supabase tokens) with:
client_idclaim for OAuth client identificationroleclaim 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:
Initial Limitations & Future Roadmap
Phase 1:
Phase 2:
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:
2. OpenID Connect Features
As we plan OIDC support, which features are most critical for you?
3. Dashboard UI for OAuth Client Management
What would you need in the dashboard?
4. Your Use Cases
What would you build with this? We're especially interested in:
Questions?
Drop your questions, feedback, and use cases below! We're actively working on this and your input will directly influence the implementation.
Beta Was this translation helpful? Give feedback.
All reactions