You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the OIDC extension, the two main claims that can be customized to verify access tokens are issuer and audience. This is fine for a lot of use cases however it gets trickier in a multi-tenant scenario where multiple organizations are mixed into the same user pool. The issuer and audience remain the same, however, providers like Auth0 insert an extra claim named org_id to represent the tenant. While it is possible to work around this on Auth0 by encoding the organization into the audience, it's not a clean implementation of what the audience claim is supposed to represent and some other providers don't have this kind of capability. It would be nice if the OIDC extension was able to validate custom claims in the access token.
Implementation ideas
I propose adding a new configuration property named quarkus.oidc.token.custom-claims. It would be a string map with the keys representing the claims and the value being the claim's target value. An example would be quarkus.oidc.token.custom-claims.org_id=org_.... If the claim's value doesn't match or doesn't exist, the authentication attempt is rejected with a 401 error.
The text was updated successfully, but these errors were encountered:
@djnalluri IMHO it makes sense. I'd only propose to name it somehow differently, these are the additional required claims, so I'd name it required-claims. Please start working on a PR, thanks
Description
In the OIDC extension, the two main claims that can be customized to verify access tokens are issuer and audience. This is fine for a lot of use cases however it gets trickier in a multi-tenant scenario where multiple organizations are mixed into the same user pool. The issuer and audience remain the same, however, providers like Auth0 insert an extra claim named
org_id
to represent the tenant. While it is possible to work around this on Auth0 by encoding the organization into the audience, it's not a clean implementation of what the audience claim is supposed to represent and some other providers don't have this kind of capability. It would be nice if the OIDC extension was able to validate custom claims in the access token.Implementation ideas
I propose adding a new configuration property named
quarkus.oidc.token.custom-claims
. It would be a string map with the keys representing the claims and the value being the claim's target value. An example would bequarkus.oidc.token.custom-claims.org_id=org_...
. If the claim's value doesn't match or doesn't exist, the authentication attempt is rejected with a 401 error.The text was updated successfully, but these errors were encountered: