mirror of
https://github.com/supabase/supabase.git
synced 2026-09-06 09:59:03 +08:00
<img width="1510" height="860" alt="image" src="https://github.com/user-attachments/assets/36a748b7-bdeb-4685-8bb1-da911711874b" /> Introduces a new OAuth consent block in preparation for offering more MCP focused blocks that require authentication and consent. The general approach for this is to decouple consent block from authentication block but provide guidance on how to use both. The alternative is to add auth as a dependency to consent but apps may already have their own authentication UI / flows. The block is also positioned as a general OAuth Consent vs MCP Consent as it can be put to use for other use cases outside of MCP on projects who want to make use of the OAuth 2.1 Server offering. A couple of changes outside of the block itself were required: - Updated the Auth blocks to allow for a `next` param to redirect users to after signing in - Updated middleware so next param is correctly passed through to sign in ## How to test Requires Docker and a Supabase CLI recent enough to support `[auth.oauth_server]` (verified on 2.109.0 / GoTrue v2.192.0). ### 1. Local Supabase with the OAuth server enabled In your `supabase/config.toml`, edit the existing `[auth.oauth_server]` section — `supabase init` already writes one, and adding a second fails with `table oauth_server already exists`: ```toml [auth.oauth_server] enabled = true authorization_url_path = "/oauth/consent" allow_dynamic_registration = true ``` Set `site_url` to wherever your test app runs (e.g. `http://localhost:3100`), then `supabase start`. Grab the API URL and publishable key from `supabase status`. ### 2. A consumer app with the blocks installed The consent block ships no login route by design, so pair it with an auth block: ```bash npx create-next-app@latest consent-test --ts --tailwind --app --yes ``` ```bash cd consent-test && npx shadcn@latest init -d -y && npx shadcn@latest add https://supabase.com/library/r/password-based-auth-nextjs.json https://supabase.com/library/r/oauth-consent-nextjs.json ``` To test this branch before it deploys, run `pnpm --filter ui-library dev` and use `http://localhost:3004/library/r/...` instead. If you changed anything under `registry/default/blocks/oauth-consent/**`, run `pnpm --filter ui-library build:registry` first — shadcn fetches the generated `public/r/*.json`, not the source. Put `NEXT_PUBLIC_SUPABASE_URL` and `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY` in `.env.local` and start the app on the port you set as `site_url`. ### 3. Register an OAuth client and start a real authorization request ```bash curl -s -X POST http://127.0.0.1:54321/auth/v1/oauth/clients/register -H "Content-Type: application/json" -d '{"client_name":"Test Client","redirect_uris":["http://localhost:3100/callback"],"grant_types":["authorization_code"],"response_types":["code"],"scope":"openid profile email"}' ``` Then open the authorize URL in a browser (not curl — you need the redirect chain and cookies): ``` http://127.0.0.1:54321/auth/v1/oauth/authorize?client_id=<id>&response_type=code&redirect_uri=http://localhost:3100/callback&scope=openid+profile+email&state=xyz&code_challenge=<challenge>&code_challenge_method=S256 ``` Auth mints the `authorization_id` and redirects to `<site_url>/oauth/consent?authorization_id=…`. An MCP client pointed at your app is an even better driver, since that's the real consumer shape. ### 4. Cases to walk | Case | Expected | | --- | --- | | Signed out, hit the authorize URL | Lands on `/auth/login?next=%2Foauth%2Fconsent%3Fauthorization_id%3D…`; after login, returns to the consent screen | | Consent screen | Shows client name, redirect URI, signed-in email, and requested scopes from `getAuthorizationDetails` | | Allow access | Redirects to `redirect_uri` with `code` and your original `state`; the code exchanges at `/oauth/token` for a real access token | | Deny | Redirects with `error=access_denied` and your `state` | | Re-run the same authorize URL after approving | Skips the screen, straight to callback with a new code | | Visit `/oauth/consent` with no `authorization_id` | "This page needs an authorization_id" | | Stale or bogus `authorization_id` | Error shown, buttons still usable | | Double-click Allow | Exactly one `POST /oauth/authorizations/<id>/consent` | Test the react, react-router, or tanstack variant the same way if you're touching them — the hook is duplicated per framework, so a fix in one doesn't carry. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added an OAuth 2.1 consent experience with client details, requested scopes, redirect URI, and approve/deny actions. * Added OAuth consent examples and registry blocks for Next.js, React, React Router, and TanStack Start. * Added OAuth documentation, navigation, and framework support across the UI library. * **Bug Fixes** * Login flows now safely preserve valid same-origin redirect destinations while rejecting unsafe URLs. * OAuth routes can handle consent flows before authentication and redirect safely to sign-in. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
94 lines
3.6 KiB
Plaintext
94 lines
3.6 KiB
Plaintext
---
|
|
title: OAuth Consent
|
|
description: OAuth 2.1 consent block for React single-page applications
|
|
---
|
|
|
|
<BlockPreview name="oauth-consent" />
|
|
|
|
## Installation
|
|
|
|
<BlockItem
|
|
name="oauth-consent-react"
|
|
description="OAuth 2.1 consent component for an existing authenticated application"
|
|
/>
|
|
|
|
## Folder structure
|
|
|
|
This block includes the [Supabase client](/library/docs/react/client). If you already have one installed, you can skip overwriting it.
|
|
|
|
<RegistryBlock itemName="oauth-consent-react" />
|
|
|
|
## Usage
|
|
|
|
This block provides an OAuth 2.1 consent component for an app that already has authentication. It does not install sign-in, sign-up, callback, or router-specific routes.
|
|
|
|
Render the component from your existing `/oauth/consent` route and pass the `authorization_id` query parameter. Set `signInPath` to the sign-in route in your app:
|
|
|
|
```tsx
|
|
import { OAuthConsent } from '@/components/oauth-consent'
|
|
|
|
export function ConsentPage() {
|
|
const authorizationId = new URLSearchParams(window.location.search).get('authorization_id')
|
|
|
|
return (
|
|
<main className="flex min-h-svh items-center justify-center p-6 md:p-10">
|
|
<OAuthConsent
|
|
className="w-full max-w-lg"
|
|
authorizationId={authorizationId}
|
|
signInPath="/login"
|
|
productName="Your product"
|
|
/>
|
|
</main>
|
|
)
|
|
}
|
|
```
|
|
|
|
When the visitor has no session, the consent screen redirects to `signInPath` and preserves the original consent URL in the `next` query parameter. After sign-in, your login page must send the visitor back to the path in `next`; otherwise the OAuth flow stops at your login screen. The password-based auth block follows `next` automatically. For a custom login page, validate that `next` is a relative path before redirecting to it:
|
|
|
|
```ts
|
|
// After sign-in succeeds:
|
|
const next = new URLSearchParams(window.location.search).get('next')
|
|
try {
|
|
const nextUrl = new URL(next ?? '/protected', window.location.origin)
|
|
location.href =
|
|
nextUrl.origin === window.location.origin
|
|
? `${nextUrl.pathname}${nextUrl.search}${nextUrl.hash}`
|
|
: '/protected'
|
|
} catch {
|
|
location.href = '/protected'
|
|
}
|
|
```
|
|
|
|
Set the `productName` prop to replace the `Your product` placeholder in the consent header.
|
|
|
|
### Getting started
|
|
|
|
After installing the block, you'll have the following environment variables in your `.env.local` file:
|
|
|
|
```env
|
|
VITE_SUPABASE_URL=
|
|
VITE_SUPABASE_PUBLISHABLE_KEY=
|
|
```
|
|
|
|
- If you're using supabase.com, you can find these values in the [Connect modal](https://supabase.com/dashboard/project/_?showConnect=true&connectTab=frameworks&framework=react&using=vite&with=supabasejs) under App Frameworks or in your project's [API settings](https://supabase.com/dashboard/project/_/settings/api).
|
|
- If you're using a local instance of Supabase, you can find these values by running `supabase start` or `supabase status` (if you already have it running).
|
|
|
|
### Configure the OAuth server
|
|
|
|
Enable the OAuth server in the Supabase Dashboard under **Authentication** > **OAuth Server**, then set its authorization URL path to `/oauth/consent`. For local development, set the following in `supabase/config.toml`:
|
|
|
|
```toml
|
|
[auth.oauth_server]
|
|
enabled = true
|
|
authorization_url_path = "/oauth/consent"
|
|
```
|
|
|
|
Recent CLI versions already write an `[auth.oauth_server]` section with `enabled = false`. Edit that section rather than adding a second one, which fails with `table oauth_server already exists`.
|
|
|
|
The route expects the `authorization_id` query parameter that Supabase Auth supplies during the authorization flow.
|
|
|
|
## Further reading
|
|
|
|
- [OAuth Server](https://supabase.com/docs/guides/auth/oauth-server)
|
|
- [Supabase Auth](https://supabase.com/docs/guides/auth)
|