Support resource-scoped Access Tokens from SpacetimeAuth (OIDC flow)

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

• OpenID Connect Core 1.0 – ID Token
• RFC 6749 §1.4 – Access Token
• RFC 9700 – OAuth 2.0 Security Best Current Practice
• RFC 8707 – Resource Indicators for OAuth 2.0
• Auth0 / Duende documentation on ID Token vs Access Token usage

Happy to help test, provide more examples, or refine the design.

Start by locating the SpacetimeAuth token endpoint and the connection layer that validates tokens. Read the linked RFC 8707 and the issue's compatibility notes before deciding how resource audiences and custom claims should be handled. Done means SpacetimeAuth can issue resource-scoped Access Tokens while existing ID Token and BYOI paths remain supported.