Refactored permission mapping in the TokenDecoder #58
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The previous methodology used JMESPaths supplied to the TokenDecoder
to map parts of the decoded token to top-level claims in the final
TokenPayload. This was added because Keycloak tokens do not put the
permission roles in the tokens as a top-level claim. Instead, they are
nested within the "resource_access" claim. The previous
`payload_claim_mapping` worked to get the permissions set correctly for
the TokenPayload, but ONLY if you knew ahead of time what the name of
the client would be.
For example, this trimmed down keycloak token has its roles found at
`resource_access.my-client.roles`:
```
{
"exp": 1728627701,
"iat": 1728626801,
"jti": "24fdb7ef-d773-4e6b-982a-b8126dd58af7",
"sub": "dfa64115-40b5-46ab-924c-c376e73f631d",
"azp": "my-client",
"resource_access": {
"my-client": {
"roles": [
"read:stuff"
]
},
},
}
```
Not that the key for the roles within the `resource_access` claim
matches the client claim (azp). Thus, we can provide an extractor for
Keycloak tokens that does not need to know ahead of time what the client
ID is.
Additionally, this allows us to remove the dependency on JMESPath.
matheushent
reviewed
Oct 14, 2024
matheushent
approved these changes
Oct 14, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The previous methodology used JMESPaths supplied to the TokenDecoder to map parts of the decoded token to top-level claims in the final TokenPayload. This was added because Keycloak tokens do not put the permission roles in the tokens as a top-level claim. Instead, they are nested within the "resource_access" claim. The previous
payload_claim_mappingworked to get the permissions set correctly for the TokenPayload, but ONLY if you knew ahead of time what the name of the client would be.For example, this trimmed down keycloak token has its roles found at
resource_access.my-client.roles:Not that the key for the roles within the
resource_accessclaim matches the client claim (azp). Thus, we can provide an extractor for Keycloak tokens that does not need to know ahead of time what the client ID is.Additionally, this allows us to remove the dependency on JMESPath.