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
Add one-of functionality to verification of list claims
Currently the verification of a claim implemented as a list using withArrayClaim() verifies the claim object using a containsAll()-function. Meaning the token must include all of the elements present in the list input to withArrayClaim().
Problem:
A "one-of" check when verifying a list claim is valid. (See for example: auth0/java-jwt#472 and the verification of Issuer. They both use the "one-of" verification. ) However it is now limited to only the hardcoded issuer and audience.
Use-case:
My company uses company-roles as a a claim in the token. ("roles: ["admin", "team-member"]). The roles I would like to verify a token with could be mutually exclusive, meaning a user only has one of them. For example: "grant access if user has either "admin" or "consultant" role.
Solution: Add "anyOf" methods in addition to the withArrayClaim()-methods.
Extend the interface to also include withAnyOfArrayClaim() similar to the withAnyOfAudience() that will verify if the claim in the token contains any of the elements in the given list.
Current workaround:
Currently we remove the withArrayClaim() from the JWTVerifier usage and rather validate the claim manually from the DecodedJWT. This has created some structural issues in the code and feels unsafe going outside the library for such an important validation step.
Additional context
This PR: auth0/java-jwt#472 essentially makes the changes, but only for audience. However audience is not the only valid "one-of" claim.
I realise withArrayClaim() is to be deprecated in the next version: auth0/java-jwt#403
This functionality will not easily be implemented with the map-based objects, as you'd have to specify each map-level as either a "one-of" or a "exact-match".
I've seen multiple attempts at "custom" or "map base" validation functionality being denied. In my eyes this is not added functionality so much as it should have been available from the get-go when withArrayClaim was added.
The text was updated successfully, but these errors were encountered:
Add one-of functionality to verification of list claims
Currently the verification of a claim implemented as a list using
withArrayClaim()
verifies the claim object using acontainsAll()
-function. Meaning the token must include all of the elements present in the list input towithArrayClaim()
.Problem:
A "one-of" check when verifying a list claim is valid. (See for example: auth0/java-jwt#472 and the verification of Issuer. They both use the "one-of" verification. ) However it is now limited to only the hardcoded issuer and audience.
Use-case:
My company uses company-roles as a a claim in the token. ("roles: ["admin", "team-member"]). The roles I would like to verify a token with could be mutually exclusive, meaning a user only has one of them. For example: "grant access if user has either "admin" or "consultant" role.
Solution: Add "anyOf" methods in addition to the
withArrayClaim()
-methods.Extend the interface to also include
withAnyOfArrayClaim()
similar to thewithAnyOfAudience()
that will verify if the claim in the token contains any of the elements in the given list.Current workaround:
Currently we remove the
withArrayClaim()
from the JWTVerifier usage and rather validate the claim manually from the DecodedJWT. This has created some structural issues in the code and feels unsafe going outside the library for such an important validation step.Additional context
This PR: auth0/java-jwt#472 essentially makes the changes, but only for audience. However audience is not the only valid "one-of" claim.
I realise
withArrayClaim()
is to be deprecated in the next version: auth0/java-jwt#403This functionality will not easily be implemented with the map-based objects, as you'd have to specify each map-level as either a "one-of" or a "exact-match".
I've seen multiple attempts at "custom" or "map base" validation functionality being denied. In my eyes this is not added functionality so much as it should have been available from the get-go when withArrayClaim was added.
The text was updated successfully, but these errors were encountered: