@dan.woda - This is very helpful, thank you! I added the exact rule from the link you provided and I’m able to see the roles in the id token and the access token returns from the spa sdk.
One thing I’m curious about is this from the rule:
let idTokenClaims = context.idToken || {};
let accessTokenClaims = context.accessToken || {};
idTokenClaims[`${namespace}/roles`] = assignedRoles;
accessTokenClaims[`${namespace}/roles`] = assignedRoles;
Does this just add the assigned roles to both the id token and the access token with a key of ${namespace}/roles? Is this specific key name significant or can it be whatever I want?
Also, why do the variables include the work Claims? Why not just call them idToken and accessToken?
Would you add the roles to the access token as well because this allows the back-end to authorized?
Is this specific key name significant or can it be whatever I want?
It can be whatever you like. Just need to be proper namespace syntax.
Also, why do the variables include the work Claims ? Why not just call them idToken and accessToken ?
You can name it whatever you like, incl. just idToken, which also makes perfect sense. Above was just an example. I would actually also name it as per your suggestion.
Would you add the roles to the access token as well because this allows the back-end to authorized?
If you need roles in the backend, then: yes. If you need to know the roles in the frontend, then the ID token is relevant.