OIDC compliance

The OpenID Connect and OAuth specifications eetr-auth implements, its discovery metadata, endpoints, and supported claims.

eetr-auth implements OpenID Connect Discovery 1.0 on top of OAuth 2.1. This page is the conformance reference: which specs are implemented, what the discovery documents advertise, and which claims can appear in tokens.

Standards implemented

Spec	Status
OAuth 2.1 (Authorization Code + PKCE, Client Credentials, Refresh Token)	✅
OpenID Connect Core 1.0 (ID tokens, `/userinfo`)	✅
OpenID Connect Discovery 1.0 (`/.well-known/openid-configuration`)	✅
RFC 8414 — OAuth 2.0 Authorization Server Metadata (`/.well-known/oauth-authorization-server`)	✅
RFC 7636 — PKCE (S256 mandatory, `plain` rejected)	✅
RFC 7591 — Dynamic Client Registration	✅
RFC 8707 — Resource Indicators (audience binding)	✅
RFC 7662-style introspection (`/api/token/validate`)	✅

Discovery endpoints

Both discovery documents describe the same issuer and endpoints and are CORS-enabled + cacheable.

Endpoint	Purpose
`/.well-known/openid-configuration`	OpenID Connect Discovery 1.0 metadata
`/.well-known/oauth-authorization-server`	RFC 8414 OAuth server metadata

Advertised metadata

The discovery document advertises (values reflect the server's actual behavior):

{
  "issuer": "https://auth.yourdomain.com",
  "authorization_endpoint": ".../api/authorize",
  "token_endpoint": ".../api/token",
  "userinfo_endpoint": ".../api/userinfo",
  "registration_endpoint": ".../api/register",
  "jwks_uri": "https://cdn.yourdomain.com/jwks.json",
  "response_types_supported": ["code"],
  "response_modes_supported": ["query"],
  "grant_types_supported": ["authorization_code", "client_credentials", "refresh_token"],
  "subject_types_supported": ["public"],
  "id_token_signing_alg_values_supported": ["RS256"],
  "token_endpoint_auth_methods_supported": ["client_secret_basic", "client_secret_post", "none"],
  "code_challenge_methods_supported": ["S256"],
  "resource_parameter_supported": true,
  "scopes_supported": ["openid", "profile", "email", "..."],
  "claims_supported": ["sub", "iss", "aud", "exp", "iat", "auth_time", "nonce", "at_hash", "name", "preferred_username", "picture", "email", "email_verified"]
}

scopes_supported is dynamic

scopes_supported reflects the scopes currently defined on the server (seeded openid, profile, email, plus any custom scopes an admin adds). jwks_uri points at the R2/CDN-served JWKS, not the Worker.

Supported claims

Claims that can appear in an issued id_token (and, for the user claims, at /userinfo):

Claim	When present
`sub`, `iss`, `aud`, `exp`, `iat`	Always
`auth_time`, `nonce`, `at_hash`	When available (`nonce` when requested)
`name`, `preferred_username`, `picture`	Gated on the `profile` scope
`email`, `email_verified`	Gated on the `email` scope

openid is required to mint an id_token and to call /userinfo. A valid token that lacks openid yields 403 insufficient_scope at /userinfo.
ID tokens are signed with RS256 using a rotatable asymmetric key pair; the public JWKS is served from the R2 CDN.
Pass nonce at /authorize to have the server bind it into the id_token; verify it on the returned token (the client library's validateIdToken does this).

PKCE & client authentication

PKCE is mandatory for the Authorization Code flow and only S256 is accepted.
token_endpoint_auth_methods_supported includes none, enabling public (PKCE-only) clients — the basis for SPA and MCP integrations.

Verifying conformance of a deployment

npm run verify:remote checks the deployed discovery document (that scopes_supported includes openid and jwks_uri resolves), that the R2 source JWKS and the CDN JWKS serve the same kid, and that the signing secrets are set. Run it after any key rotation or schema migration — see Operations → Secrets & key rotation.