feat(auth): Implement issuer allow-list and required-auth flag

[ImGajeed76]

Description of Changes

This PR introduces critical security enhancements to the JWT authentication and authorization flow, hardening the server for production environments.

1. Issuer Allow-List: A new --allowed-oidc-issuer CLI flag has been added. It can be specified multiple times to build a whitelist of trusted OIDC providers. The validation logic now checks the token's iss claim against this list before proceeding with OIDC validation. If the list is not configured, a prominent security warning is logged at startup to alert operators of the permissive default.

2. Required Authentication: A new --auth-required CLI flag has been added to disable the on-the-fly creation of anonymous users. When this flag is enabled, any connection attempt that does not present a valid JWT will be rejected with a 401 Unauthorized error. This is a crucial feature for private or permissioned deployments.

3. Authentication Flow Fix: A logic bug in the anon_auth_middleware has been corrected. Previously, a request with an invalid token would fail validation but would then incorrectly fall back to the anonymous user creation flow. The logic has been refactored to ensure that an invalid token immediately terminates the request with a 401 Unauthorized error, correctly distinguishing it from a request that provides no token at all.

These changes are plumbed through the application stack, from the start subcommand's CLI parsing, through the StandaloneEnv state, and into the auth module where the logic is enforced.

API and ABI breaking changes

There are no external API or ABI breaking changes for clients interacting with the server. The new CLI flags are additive and the server's default behavior remains the same (though now with a security warning). Internal function signatures for StandaloneEnv::init and default_auth_environment have changed, but these are not part of the public-facing API.

Expected complexity level and risk

Complexity: 2/5

The changes touch several core files (start.rs, main.rs, auth.rs, token_validation.rs), but the logic itself is straightforward. The primary complexity lies in correctly plumbing the configuration from the CLI down to the middleware where it is used.

The risk is low to moderate. The main risk is an incorrect implementation of the authentication flow, which could either improperly reject valid users or improperly accept invalid ones. However, the new logic is more explicit and robust than the previous implementation, reducing the overall risk profile of the auth system. The default behavior is unchanged, minimizing the impact on existing development workflows.

Testing

Manual testing has been performed to validate the new functionality:

• Started the server with --allowed-oidc-issuer https://accounts.google.com. Verified that a token from a different issuer is rejected, while a connection with no token still succeeds (creates an anonymous user).
• Started the server with --auth-required. Verified that a connection attempt with no token is rejected with a 401 Unauthorized error.
• Started the server with no new flags. Verified that a request with a deliberately invalid/expired token is rejected with a 401 Unauthorized error and does not create an anonymous user.
• Verified that the security warning for a missing issuer allow-list is logged correctly at startup.

Reviewers are encouraged to sanity-check these flows, particularly the interaction between the --auth-required flag and the subscribe endpoint.

[CLAassistant]

All committers have signed the CLA.

[gefjon]

Thanks for your submission! In general, we don't want to do auth-related configuration on a global/per-host level, we want it to be per-database. SpacetimeDB is designed as a multi-tenant system, and different databases may have different auth requirements. We'd also prefer to configure the SpacetimeDB host via the config file, rather than through command-line flags. As to the specific changes you've made:

1. Issuer Allow-List

Rather than having this enforced by the host, we intend to expose JWTs' claims to reducers, including client_connected, to allow the module code to discriminate as it sees fit. We put this work on hold to support the BitCraft early access launch, but will be returning to it soon.

2. Required Authentication

Again, we'd like module code to be able to discriminate programmatically, rather than having the host enforce this.

3. Authentication Flow Fix

This is a valuable bugfix which we'd like to merge. Would you be willing to separate it into its own PR?