JWKS
A specification (RFC 7517) for publishing sets of public keys in standard JSON format. It enables identity providers to dynamically expose public keys to relying parties, supports matching specific keys via Key ID (kid), and is used in conjunction with key rotation mechanisms.
Timeline (last 90 days)
OIDC tokens are signed with a private key by a trusted issuer, and the recipient verifies the signature using the public key obtained from the issuer's public JWKS endpoint, without needing real-time communication with the issuer.
The public keys required to verify tokens from third-party identity providers are typically fetched dynamically via a JWKS endpoint, and the server needs to match the corresponding key based on the kid in the token header.
In Elixir, a GenServer or ETS table can be used to cache the JWKS key set in memory with a refresh cycle, to avoid requesting the JWKS endpoint on every verification.
During key rotation, the JWKS endpoint publishes both the new and old public keys simultaneously (distinguished by different kids), allowing verifiers to still validate existing tokens issued with the old key during the transition period.
When the kid carried by a token cannot be found in the cache, a forced refresh should be triggered rather than directly rejecting the request, in order to handle the race window during key rotation.
JWKS is a standard for publishing a set of public keys in JSON format; IdPs typically expose this endpoint via the jwks_uri field in the OpenID Connect Discovery document (/.well-known/openid-configuration).
When an unknown kid is encountered, a forced JWKS refresh should be triggered rather than directly rejecting the request, in order to avoid false rejections during key rotation.
A JWKS cache-miss flooding attack can force each request to trigger a remote JWKS fetch by forging large numbers of invalid JWTs carrying different kid values, launching a distributed denial-of-service attack against the authorization server.
The JWKS (JSON Web Key Set) endpoint is the standard mechanism for distributing public keys.
All Facts (9)
OIDC tokens are signed with a private key by a trusted issuer, and the recipient verifies the signature using the public key obtained from the issuer's public JWKS endpoint, without needing real-time communication with the issuer.
50%UnverifiedThe public keys required to verify tokens from third-party identity providers are typically fetched dynamically via a JWKS endpoint, and the server needs to match the corresponding key based on the kid in the token header.
50%UnverifiedIn Elixir, a GenServer or ETS table can be used to cache the JWKS key set in memory with a refresh cycle, to avoid requesting the JWKS endpoint on every verification.
50%UnverifiedDuring key rotation, the JWKS endpoint publishes both the new and old public keys simultaneously (distinguished by different kids), allowing verifiers to still validate existing tokens issued with the old key during the transition period.
50%UnverifiedWhen the kid carried by a token cannot be found in the cache, a forced refresh should be triggered rather than directly rejecting the request, in order to handle the race window during key rotation.
50%UnverifiedJWKS is a standard for publishing a set of public keys in JSON format; IdPs typically expose this endpoint via the jwks_uri field in the OpenID Connect Discovery document (/.well-known/openid-configuration).
50%UnverifiedWhen an unknown kid is encountered, a forced JWKS refresh should be triggered rather than directly rejecting the request, in order to avoid false rejections during key rotation.
50%UnverifiedA JWKS cache-miss flooding attack can force each request to trigger a remote JWKS fetch by forging large numbers of invalid JWTs carrying different kid values, launching a distributed denial-of-service attack against the authorization server.
50%UnverifiedThe JWKS (JSON Web Key Set) endpoint is the standard mechanism for distributing public keys.
50%