feat: function to locally validate a JWT

[paulswartz]

Many access tokens are JWTs, which clients can validate without needing to use the token_introspection endpoint. This allows multiple clients using the same issuer to use access tokens as a means of validation between them.

[maennchen]

The implementation loads all supported signing / encryption algorithms. That will probably even include none if that is enabled in jose.

    {jws, {alg, SigningAlgs}} = jose_supports(jws),
    {jwe, {alg, EncryptionAlgs}, {enc, EncryptionEncs}, _} = jose_supports(jwe),

I believe this is not a safe assumption to make.

My idea so far was to allow verifying access tokens as id tokens. You can see this here: Oidcc.Plug.ValidateJwtToken

I see three routes to handle this:

• Allow to verify with the same rules as id token (as it is right now; possibly expand the docs to explain this use case)
• Provide a dedicated function but with a lot more arguments for signing / encryption parameters (no magic, user has to think about it and provide valid options)
• Do not offer access token verification at all since it is not part of the standard (i think...?). Users have to use jose & possibly the openid configuration metadata directly.

[paulswartz]

For this particular case, the access token will not validate as an ID token at a different client because the "azp" claim only matches the initial client. However, the other clients are listed in "aud". The Zitadel CT test doesn't really cover this unfortunately, as it doesn't return an "azp" claim.

What do you think about using the JOSE values as defaults (possibly even filtering out "none") but allow them to be overridden in Opts?

[maennchen]

The whole topic with azp possibly deserves a solution in general. The standard is very clear on it, but just doesn’t reflect what I saw so far in reality.

I don’t think just allowing everything (possibly besides none) is a safe default.