JWT claim as escaped string (not Object) #3696
Open
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.
Further to PRs #3560 and #3692.
Now that is it possible to specify any claim key for the permissions within the JWT, the next step is to allow for OAuth providers that do not support (or only support in certain use cases) object claims. Specifically in the case of AZ B2C extension claims are permitted to be
bool
,int
orstring
. To over come this limitation is is possible to put the permissions in the claim as a stringified JSON object.So this below (as it appears when using the keycloak example in the README.md)
Becomes:
The changes in #3692 capture the
rawPermissions
as part of the claim extraction process, the changes in this PR inject at this point to determine if thejson.RawMessage
is a sting based on the leading character. If it is a string then a string conversion is conducted to unquote it. The result is then passed on to the remainder of the extraction function.(@aler9 you, having read my poor attempts at go, will no doubt realise that go is not my first language, so I assume there is a better way of checking to see if the
rawPermissions
is in fact a string - if you know it then i am all ears)