Feature request
Support RFC 8707 Resource Indicators in the OAuth 2.1 authorization server: accept the resource parameter at the authorization and token endpoints, validate it, and bind the issued access token's aud claim to that resource URI.
Why
The MCP authorization spec requires resource-bound tokens: MCP clients send resource per RFC 8707, and strict native connectors (Claude Desktop and web, ChatGPT) reject or mis-scope tokens whose audience is not the MCP resource URL. Today the Supabase OAuth server ignores the resource parameter and stamps aud: "authenticated", so a Supabase-backed MCP resource server cannot satisfy the spec's audience-binding requirement with Supabase-issued tokens — the resource server has no way to influence the audience since only the token issuer can set it.
Current behavior
/oauth/authorize + token endpoint: resource parameter accepted-but-ignored.- Issued access tokens:
aud: "authenticated" regardless of the requested resource.
- RFC 9728 protected-resource metadata on the resource-server side points clients at Supabase as the authorization server, but the tokens that come back are not audience-bound to the resource.
Desired behavior
- Accept
resource at both the authorization and token endpoints (RFC 8707 semantics, including the multiple-resources / downscoping rules).
- Validate the requested resource (e.g., against a per-client allowlist of registered resource URIs, or a project-level configuration).
- Issue the access token with
aud set to the granted resource URI (keeping "authenticated" as an additional audience would preserve backward compatibility with PostgREST/RLS consumers: aud: [resource, "authenticated"]).
- Advertise support in the authorization-server metadata.
Impact
This unblocks the growing class of MCP servers that use Supabase Auth as their identity provider from having to stand up their own authorization server in front of Supabase purely to control the aud claim. With resource indicators supported, a Supabase-backed MCP server works with zero-config native connectors out of the box.
Happy to provide more detail on the MCP flow or test against a preview build — we run a production MCP resource server on Supabase Auth today and currently have to plan a wrapper AS solely for this gap.
Feature request
Support RFC 8707 Resource Indicators in the OAuth 2.1 authorization server: accept the
resourceparameter at the authorization and token endpoints, validate it, and bind the issued access token'saudclaim to that resource URI.Why
The MCP authorization spec requires resource-bound tokens: MCP clients send
resourceper RFC 8707, and strict native connectors (Claude Desktop and web, ChatGPT) reject or mis-scope tokens whose audience is not the MCP resource URL. Today the Supabase OAuth server ignores theresourceparameter and stampsaud: "authenticated", so a Supabase-backed MCP resource server cannot satisfy the spec's audience-binding requirement with Supabase-issued tokens — the resource server has no way to influence the audience since only the token issuer can set it.Current behavior
/oauth/authorize+ token endpoint:resourceparameter accepted-but-ignored.aud: "authenticated"regardless of the requested resource.Desired behavior
resourceat both the authorization and token endpoints (RFC 8707 semantics, including the multiple-resources / downscoping rules).audset to the granted resource URI (keeping"authenticated"as an additional audience would preserve backward compatibility with PostgREST/RLS consumers:aud: [resource, "authenticated"]).Impact
This unblocks the growing class of MCP servers that use Supabase Auth as their identity provider from having to stand up their own authorization server in front of Supabase purely to control the
audclaim. With resource indicators supported, a Supabase-backed MCP server works with zero-config native connectors out of the box.Happy to provide more detail on the MCP flow or test against a preview build — we run a production MCP resource server on Supabase Auth today and currently have to plan a wrapper AS solely for this gap.