-
-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: function to locally validate a JWT #330
Conversation
The implementation loads all supported signing / encryption algorithms. That will probably even include {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: I see three routes to handle this:
|
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 |
The whole topic with I don’t think just allowing everything (possibly besides |
c5177e0
to
942eb45
Compare
942eb45
to
164d75f
Compare
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.
164d75f
to
7a8ead6
Compare
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.