a claim with RESOURCEclaimType and value with valueTypeEXPRESSION and expression itself set to getFilteredGroups(app.profile.allowgrouplist, \"group.name\", 40)
a scope that is used to “trigger” the claim above
I don’t know why but for some reason, when requesting the token, the claim is always absent.
Where did you configure your custom claim, as part of a custom authorization server? Can you maybe share a screenshot of what this looks like within the admin console?
If you added this to a custom authorization server, when you request tokens, are you requesting them from the same authorization server on which you added the claim: check the “iss” claim value within the resulting token to confirm which authorization server issued it.
Hi @andrea! Thanks for the answer.
It seems like I’m creating the claim on default authorization server. The iss in JWT is https://<domain>/oauth2/default and in server configuration I see default: true. It is definitely for the same auth server as there’s only one there. Not sure if that’s a “custom” one or not. How can I figure that out?
Anyway, I’ve just tried on the okta instance, where there are several authorization servers, with a non-default one - same result, no custom claim present in JWT.
Here are the details on configuration:
Okta group with type: OKTA_GROUP
Application with grant type client credentials supported and assigned to the group above. Application has allowedgrouplist property set within its profile configuration section
Scope to be used to set up a custom claim
Custom claim with valueType: EXPRESSION, claimType: RESOURCE and value: getFilteredGroups(app.profile.allowgrouplist, "group.name", 40). I also tried with the group UID as the first parameter (getFilteredGroups({"group-uid"}, "group.name", 40)) but with the same result
ah, that’s whats doing it then. You cannot receive group membership information for an application as a groups claim. Our group functions/expressions will only work if there is a user in context and will not work during Client Credentials flow. If you completed Authorization Code flow instead, do you receive the groups claim in your tokens?
If you want this type of information included in an Access Token issued during Client Credentials flow, you could look to use Token Inline Hooks to enrich the token with this information, such as by having your hook endpoint make API calls to Okta to retrieve the group information.
Regarding that Token Inline Hooks approach - will that work with Client Credentials as well? It is stated to be used for Authorization Code flow only. It is even stated as a required step during configuration when creating Okta application integration.
Ah, I should have sent the reference doc instead: Token inline hook reference | Okta Developer. But yes, token inline hooks will also be triggered during Client Credentials flow