How do you actually request custom federated claims in OIDC auth code flow?

[joekrie]

Referring to the custom federated claims from this answer: Groups_claim field is deprecated
And the doc here: Configure custom claims for app integrations | Okta Classic Engine

The answer from above says that using federated claims “allows you to configure custom claims at the application level and does not require use of a custom authorization server”.

I am unable to access a custom groups claim using the example here: user.getGroups({'group.type': {'OKTA_GROUP', 'APP_GROUP', 'BUILT_IN'}})).![name]

If I add custom claims with hard coded values wrapped in single quotes, those claims automatically show up in the /userinfo response. However, any claims that use any other expression do not show up in the /userinfo response:

What is the correct way to retrieve these custom claims from the application?

[andrea]

For your created_test claim, there isn’t a user.created value that can be pulled in via Okta Expression Language, so I’m not surprised that that one isn’t working

For your groups_test can you try switching your expression to user.getGroups({'group.type':{'OKTA_GROUP','APP_GROUP'}}).![profile.name]? This expression is working for me when I tested it just now

Finally, I’m not actually having any issue with the sess_amr_test claim. I have the same configuration as you and I’m seeing the claim returned directly in the ID token payload

[joekrie]

Thank you!

1. That change you suggested worked for the groups_test claim. However, the screenshot in the forum question I linked has just ![name], so it’d be helpful if there was a note on that answer for anyone else who comes across it.
2. I do see that the sess_amr_test does appear on the id_token but not the /userinfo response. I’m guessing that’s by design, that “session” simply doesn’t exist in the context of /userinfo.
3. user.created is an example that I took from here: Okta Expression Language in Identity Engine | Okta Developer .

[andrea]

1. Good thinking! I just updated my screenshot in that thread with the expression we both tested and confirmed as working
2. Hmm, that I’m not sure about but I am seeing the same thing as you, with the claim appearing in the ID token itself, but not at /userinfo. Your theory makes sense to me though.
3. The reason I said what I did is that the syntax for these “federated” claims is a little different than what is used in Profile Mappings, and our doc here mentions that you can access User Profile Attributes using the express user.profile.{$property} but doesn’t show a way to access system properties like created

[joekrie]

Gotcha, makes sense, thank you.