Custom claims does not show up on id-token for OIDC

Questions OAuth/OIDC
1

Hello there,
I am using this article: Customize tokens returned from Okta with custom claims | Okta Developer to set up a custom claim in the ID token. I want to include something related to the user here: the first name, username, or email (I don’t have a preference).

I have configured a claim called IDTClaim with the following configurations:

image
image1703×1298 177 KB

When I add the custom claim to the default authorization server and preview the token, I can see the custom claim :

image
image2277×1746 246 KB

However, when I run the application and receive the id token, it no longer has the new custom claim in the id token:

image
image1311×796 138 KB

Any idea why this could be happening?

2

Based on that final screenshot of yours, looks like your application is configured to use the Org Authorization Server (iss = “https://trial-xxxx.okta.com”), which means that you will not receive any custom claims you created on a separate, Custom Authorization Server.

If you update your application configuration to use the custom authorization server (usually this involves changing a setting called Issuer or Authority, but the name can vary from library to library) instead.

Lastly, I should also note that claims like user first name, username, and email all translate to standard OIDC claims that will be returned when your application requests the profile and email scopes. The first name will be found in “given_name”, username in “preferred_username”, and email in “email.” More details about these standard claims (and the associated scopes) here: Scope-dependent claims | OpenID Connect & OAuth 2.0 API | Okta Developer

Keep in mind that if your application requests both the ID token and the Access Token in a single request, a lot of these user profile scopes will only be available by sending the access token along to the Userinfo endpoint. More details about why this happens here: Okta Groups or Attribute Missing from ID Token | Okta Help Center

3

Hello,
Thank you for your quick response.
I just wanted to confirm, do I still need to change the issuer/authority to refer to a custom authorization server even if I added the custom claims to the Default authorization server?
Additionally, do you have instructions for how to change the issuer for my application?
I don’t see any option to specify the issuer on the admin console:

image
image1757×1158 181 KB

Is this something I should do on client side when configuring the application’s deployment settings?

Additionally, please note that the client I am using to host the web application does not yet support additional claims. As a result, we are not able to specify profile or email scopes yet to request that additional information.

The web application currently reads the id_token to extract the information we need. If I could change it to read the access token then I could have easily read the “sub” claim and gotten the username, however, this is not something I can change. So, if we could configure the client on the Okta console to include the username in the id_token, that would be awesome.

4

The Default Authorization Server is different from the Org Authorization server, so, yes, you would need to update your application (and yes, this would be in the application config/deployment settings on your side, not within Okta) to use the default server as the issuer: https://trial-xxx.okta.com/oauth2/default

The screenshot you’ve shared is for the Org Authorization Server, and its so you can configure the app to work with either the Okta domain or a custom domain you’ve configured for your org. If you’re using a custom authorization server (such as the one confusingly named “default”), then you don’t have to worry about this section in Application → Sign On.

And yeah, if you can’t request additional scopes or make a request to userinfo, then it makes sense to use a custom authorization server and create claims that will always be returned within the ID token itself.