RFC 7519 — JSON Web Token — Versola Docs
/docs
Pre-1.00.7.5versola.ioGitHub
RUEN

RFC 7519 — JSON Web Token

JWT structure, signing algorithms and claims used for access tokens, ID tokens and other signed objects.

Specification: RFC 7519

JSON Web Tokens carry signed claims that can be verified without calling the authorization server. Versola uses them for access tokens (the RFC 9068 profile), ID tokens, UserInfo and JARM responses, and logout tokens.

Status

Partially implemented. Checked claims: 17 of 22.

Signing algorithms

Tokens are signed with the key the tenant selected, so the algorithm is the one that key is published under (see RFC 7517).

  • PS256 — RSASSA-PSS with SHA-256; allowed on every tenant
  • ES256 — ECDSA with P-256 and SHA-256; allowed on every tenant
  • RS256 — RSA PKCS#1 v1.5 with SHA-256; allowed as a signing key on standard tenants only, refused on fapi2 tenants
  • HS256 — HMAC with SHA-256; used only for internal service tokens between auth, central and edge, never published
  • EdDSA — not supported
  • ES384, ES512, PS384, PS512, RS384, RS512 — not supported

Algorithms accepted on inbound signed objects:

ObjectAccepted algorithms
DPoP proof (RFC 9449)ES256, PS256 by default; RS256 only if the operator names it in dpop_signing_alg_values_supported
Client assertion (RFC 7523)ES256, PS256 by default; RS256 only if named in token_endpoint_auth_signing_alg_values_supported
Request object (RFC 9101)ES256, PS256 by default; RS256 only if named in request_object_signing_alg_values_supported

Standard claims (Section 4.1)

  • iss — issuer
  • sub — subject (user or client identifier)
  • aud — audience
  • exp — expiration time
  • iat — issued at time
  • jti — unique JWT identifier
  • nbf — not set on issued access tokens or ID tokens; introspection reports it only for a token that carries one

JOSE header fields

  • alg — signing algorithm
  • typ — JWT for ID tokens and other signed objects, at+jwt for access tokens
  • kid — key identifier for key rotation

Validation

  • Signature verification against the JWKS, by kid
  • Expiration check (exp)
  • Exact typ check — an ID token cannot be used as an access token
  • Unsigned (none) tokens are rejected, because every token must resolve to a key by kid
  • nbf enforcement on inbound tokens — not enforced, because issued tokens do not carry nbf
  • JWE (encrypted JWT) — not supported

Access token profile

Access tokens follow the JWT Profile for OAuth 2.0 Access Tokens (at+jwt). Beyond the registered claims they carry client_id, scope, roles, tenant_id, sid, fam and cnf, as well as acr, amr and auth_time for user tokens, and authorization_details when the grant has them.

Notes

  • Which algorithms each tenant profile allows is summarised in Security profiles.
  • id_token_signing_alg_values_supported comes from the stored discovery document and is not derived from the tenant’s key.

Where to look

Security profiles lists which signing algorithms each tenant profile allows.