Description

Although the new OidcTokenHandler is a great step forward, I believe the name is confusing because it's just validating a simple JWT token (as defined by RFC 7519) and not really using the advantages of OIDC.

Every OIDC issuer (eg https://securetoken.google.com/helloworld) has a corresponding discovery endpoint which is conveniently accessible by appending .well-known/openid-configuration (eg https://securetoken.google.com/helloworld/.well-known/openid-configuration)

The OIDC token handler should accept a simple issuer, load the list of keys from jwks_uri property of the discovery endpoint, ideally cache those keys for a short amount of time and validate the JWT token against those.

The advantages are a simpler configuration for the developer (only issuer & claim needs to be configured) and issuer can change the endpoints or execute key rotations without the need to reconfigure the client applications. Please note that once the keys are cached, this method doesn't need to issue any HTTP requests to validate the token.

Some OIDC discovery endpoints (eg https://accounts.google.com/.well-known/openid-configuration or https://e2emerchant.itsme.be/oidc/.well-known/openid-configuration) contain more information, like userinfo_endpoint which is already used in the OidcUserInfoTokenHandler (but without support for the discovery endpoint), support for token revocation and also the actual login flow configuration which might also be used for stateful firewalls.

Also an important distinction is that in OIDC the claims are stored in the ID token, while the current implementation is validating the access token only. Most of the time they are identical, but in fact, OIDC access tokens might not even be a JWT.

In my opinion the OidcTokenHandler should be renamed to JwtTokenHandler

Example

No response