Summary
Add support for SpacetimeAuth to mint Access Tokens that follow standard OIDC/OAuth 2.0 practices when connecting to SpacetimeDB modules.
Currently SpacetimeDB expects (and documents) the use of ID Tokens for WebSocket connections. While this works and simplifies bring-your-own-issuer (BYOI) scenarios, it diverges from the intended use of ID Tokens vs Access Tokens and creates friction for client developers.
Original Discord discussion
The Problem
- ID Tokens are intended for the client application (Relying Party) to verify identity (
aud = client_id).
- Access Tokens are intended for resource servers (SpacetimeDB host) to authorize access (
aud = resource URI).
- When a client opens a WebSocket connection and presents a token, SpacetimeDB is acting as a resource server. Presenting an ID Token in this context re-purposes it for authorization.
- SpacetimeAuth Access Tokens currently lack useful claims (e.g.
steam_owned_games, user metadata) and a proper resource audience, forcing special-casing in client code.
This makes it harder to write clean, uniform auth code that follows standard OIDC library patterns.
Proposed Solution
Add support in SpacetimeAuth for a resource-audience / resource parameter on the token endpoint (aligned with RFC 8707 – Resource Indicators for OAuth 2.0).
Desired Behavior
- Client can request a token with an audience, e.g.:
audience=https://maincloud.spacetimedb.com
- SpacetimeAuth issues an Access Token with:
aud set to the requested resource (the SpacetimeDB host / module URI)azp (or a client_id claim) containing the original client identifier- Useful custom claims currently only present on ID Tokens (e.g.
steam_owned_games)
- SpacetimeDB (or the connection layer) can validate the
aud claim as a standard resource check. Module code can still inspect other claims for application-specific authorization.
Benefits
- Aligns with OpenID Connect Core, RFC 6749, RFC 9700 (Security BCP), and RFC 8707.
- Removes the need for provider-specific branching in client code.
- Keeps full BYOI support (ID Tokens remain available as a fallback for issuers that don’t support custom audiences, e.g. Firebase, or raw non-OIDC tokens like Discord/GitHub).
- Improves developer experience when using standard OIDC libraries.
Compatibility Notes
When SpacetimeAuth is used as the issuer (or as a broker), we can follow the OIDC spec cleanly. For third-party / non-standard issuers that cannot issue resource-scoped tokens, the existing ID Token path can continue to work.
Supporting the standard Access Token flow for SpacetimeAuth (and other compliant OIDC providers such as Auth0, Cognito, etc.) covers the vast majority of use cases without breaking BYOI.
Additional Context / References
Happy to help test, provide more examples, or refine the design.
Summary
Add support for SpacetimeAuth to mint Access Tokens that follow standard OIDC/OAuth 2.0 practices when connecting to SpacetimeDB modules.
Currently SpacetimeDB expects (and documents) the use of ID Tokens for WebSocket connections. While this works and simplifies bring-your-own-issuer (BYOI) scenarios, it diverges from the intended use of ID Tokens vs Access Tokens and creates friction for client developers.
Original Discord discussion
The Problem
aud=client_id).aud= resource URI).steam_owned_games, user metadata) and a proper resource audience, forcing special-casing in client code.This makes it harder to write clean, uniform auth code that follows standard OIDC library patterns.
Proposed Solution
Add support in SpacetimeAuth for a resource-audience / resource parameter on the token endpoint (aligned with RFC 8707 – Resource Indicators for OAuth 2.0).
Desired Behavior
audience=https://maincloud.spacetimedb.comaudset to the requested resource (the SpacetimeDB host / module URI)azp(or aclient_idclaim) containing the original client identifiersteam_owned_games)audclaim as a standard resource check. Module code can still inspect other claims for application-specific authorization.Benefits
Compatibility Notes
When SpacetimeAuth is used as the issuer (or as a broker), we can follow the OIDC spec cleanly. For third-party / non-standard issuers that cannot issue resource-scoped tokens, the existing ID Token path can continue to work.
Supporting the standard Access Token flow for SpacetimeAuth (and other compliant OIDC providers such as Auth0, Cognito, etc.) covers the vast majority of use cases without breaking BYOI.
Additional Context / References
Happy to help test, provide more examples, or refine the design.