Profile Scope Missing given_name claim

[grbinho]

Hi,

I created a Web application in Okta with Authorization Code grant type. I’m requesting two scopes from the application “openid” and “profile”.

But the profile scope only returns very limited set of claims.
For example, it’s missing “given_name” and “family_name” claims.

The user I’m testing this with has bot “firstName” and “lastName” filled.

If I try to create that claim for ID token, I get an error that it’s a duplicate claim.

Is there are reason why I’m not getting full set of available claims back?
Can this be configured somewhere? I was not able to find it.

Thanks for the help!

[phi1ipp]

You can create an additional claim(s) and specify which user attribute you want to include in each, and add those claims into openid scope

[grbinho]

Hi phi1ipp.

I’m aware of that, but the problem is that “given_name” and “familiy_name” are standard openid id token claims. Okta does not seem to expose these claims in the profile scope when it should.

Check section 5.4 in this document
https://openid.net/specs/openid-connect-core-1_0.html

When I check the profile mappings for my app, they are configured correctly.
user.firstName is mapped to given_name and user.lastName is mapped to family_name.
They just never show up in the id token.

Of course, I can create completely different claims that are filled with the same data, but that will not be following openid standards and It would make the configuration more fragile.

[phi1ipp]

Are you trying to get those claims from /userinfo endpoint?

[grbinho]

I’m using this in Airflow (fab oidc). From what I can tell, if the claim is not present in the token, it will try to get the info from /userinfo endpoint.

But apart from the app, I also tried this in the Okta admin portal.
I got the token there for the same user and authorization server and it was missing the above claims.

Not sure what I’m missing here.

[tquenan]

Any resolution to this? I’m seeing the same problem when connecting to Okta using the MiniOrange OpenID Connect plug-in in WordPress. The expected standard claims aren’t included and any custom claims I add don’t appear in what’s presented back to the plug-in.

[phi1ipp]

maybe profile scope is not requested? can you check that?

[tquenan]

I am most definitely requesting the profile scope (along with openid and email). I also know the profile scope is being requested because the “name” field is part of the response. I’d just like to see given_name and family_name always included, but for some reason Okta has those not included in the token. Is there a way to turn those standard claims to the alwaysIncludeInToken value is set to true?

From the claims api endpoint:

{“id”:“ocl1hq77nmjzH13iy0h8”,“name”:“family_name”,“status”:“ACTIVE”,“claimType”:“IDENTITY”,“valueType”:“SYSTEM”,“conditions”:{“scopes”:[“profile”]},“system”:true,“alwaysIncludeInToken”:false,"_links":{“self”:{“href”:“https://apps.tiger21.com/api/v1/authorizationServers/default/claims/ocl1hq77nmjzH13iy0h8",“hints”:{“allow”:[“GET”,“PUT”,“DELETE”]}}}},{“id”:“ocl1hq77nmnEFVteF0h8”,“name”:“given_name”,“status”:“ACTIVE”,“claimType”:“IDENTITY”,“valueType”:“SYSTEM”,“conditions”:{“scopes”:[“profile”]},“system”:true,“alwaysIncludeInToken”:false,"_links":{“self”:{“href”:“https://apps.tiger21.com/api/v1/authorizationServers/default/claims/ocl1hq77nmnEFVteF0h8”,“hints”:{“allow”:[“GET”,“PUT”,"DELETE”]}}}},

[phi1ipp]

oh, I see that they are not included by default, just checked on my default server.

What I figured is that they are included, if you use Implicit flow (hybrid). At least they are visible in ‘Token Preview’

[tquenan]

phi1ipp, yeah I see those fields are included in the token preview when using Implicit flow; however the MiniOrange OpenID Connect Word Press plug-in I’m using doesn’t work when I try to set it up with implicit grant.

[phi1ipp]

The OIDC RFC says (see below). Is there a chance to get any details of your plugin communication with Okta, to troubleshoot further?

The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 5.3.2, when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token.

[tquenan]

phi1ipp,

Thanks for the response. I have opened a support request with the plug-in vendor. Trying to determine what API calls they make to pull the information. Here’s a screen shot from the plug-in test confirmation where you can see the Name attribute come through but not given_name and family_name.

[phi1ipp]

Yeah, it seems like it’s the token received right away from /token endpoint, not the one from /userinfo