How to make an app with multiple permission levels?

Hi there,

We have an OIDC app in Okta’s public OIN marketplace/store. Currently it only authenticates users into one specific role-type, but we’re looking to add additional role-types.

I’m seeing a couple of different options here:

  1. Is there some way, on Okta’s side, to create a list of roles, and let an admin specify which groups of users get which roles, with our application?

  2. Or do we need to make a separate application per role?

  3. Or should we let Okta admins install the same application multiple times, and keep track on our side of which installation is associated with which role type?

I’m not even sure which of these solutions, if any, are possible and/or recommended. Would appreciate some advice here. Thanks!

Hi there, can someone offer some insight here?

As you have mentioned, normally developers can use group claims to determine what permissions the user has based on the groups they’re assigned to. However, group claims is not currently supported for OIN OIDC apps.

An alternative could be to create a custom attribute on the Okta user profile and then map that value to a custom attribute on the app user profile. However, the customer would have to update the value for all users which could be tedious even if they use the Okta API.

The second alternative could be to create multiple custom attributes on the app user profile. All app assignments would be done using group assignments where you can specify value(s) for the attribute(s).

For both of these alternatives, you’ll want to request the profile scope and the response from the /userinfo endpoint should contain the information.

1 Like

Hi @okra-okta, thank you for your response.

Can you please clarify how I would get started on setting up the third solution:

  1. How can I “create multiple custom attributes on the app user profile”?

  2. How can I “use group assignments to specify value(s) for the attribute(s)”?

Are these things that I do as the public app developer, or things that I have to instruct our customer to do themselves? Are there relevant help articles?

Hmm, so I think I was able to achieve the above. I created two custom attributes on the app user profile, and used group assignments to specify values for the attributes. But then in the /userinfo request, I did not receive any of the custom attributes I created + mapped.

I confirmed that I am including the profile scope in the authorization request, and the custom attributes do have values set on the user I am testing with… Any ideas?

Can you double check that you’re using the right issuer? You should be making requests to https://oktaDomain/oauth2/v1/authorize and https://oktaDomain/oauth2/v1/token

1 Like

Hi @andrea, thanks for your response! That’s correct, I am using those URLs.

My Okta test domain is, so the URLs I’m using are and

I’m a little perplexed, it seems like you’re doing everything right. Which claims do you see come back when you make a request to userinfo?

Here’s what I’m getting back from /userinfo:

  sub: '00u3g38yfwXSAPkbf4x7',
  locale: 'en-US',
  email: '',
  preferred_username: '',
  given_name: 'Andrew',
  family_name: 'Rasmussen',
  zoneinfo: 'America/Los_Angeles',
  updated_at: 1623263749,
  email_verified: false

Interestingly, these claims are all included in claims_supported at Do I need to somehow add additional claims to the openid-configuration? If so, how would I go about doing that?

If you check{{{your client ID}}, do you see the custom attributes listed as part of claims_supported

1 Like

Yep! So it looks like the authorization server knows about the custom claims, but isn’t adding them to the token/userinfo… Any ideas why that might be?

Are the claims set by the values in the okta user profile or the app user profile?

  • When I open the app user (Application > Assignments > People), I see that my custom attributes are correctly set (based on group membership).
  • When I open the user in the directory (Directory > People > ${user} > Profile), my custom attributes are undefined.

Does this mean my mapping isn’t set up correctly?

I’ve tried manually setting the values on the Okta user profile, I’ve tried mapping Okta → app profile, and app profile → Okta. Nothing seems to add the custom attributes to userinfo…

Hi @andrea, do you have any idea how we can proceed here?

Hi a12n,
Just checking, did you specify those claims should be in the ID_Token and /userinfo endpoint? You can also force them to only be present if they’re tied to a scope.

Hi Abole, thanks for your response.

That looks like the custom authorization server page, but I’m using the Okta authorization server, not a custom one.

Do I need to be using a custom authorization server in order to get custom attributes via /userinfo?

It seems like the answer is yes based on Okta Help Center (Lightning)

Yeah, I’m pretty sure you need a custom auth server as the default auth server has constraints. See Authorization Servers | Okta Developer

“If your application has requirements such as additional scopes, customizing rules for when to grant scopes, or you need additional authorization servers with different scopes and claims, then you need to create a Custom Authorization Server.”

@abole this article seems to state otherwise:

“If you do not have a custom authorization server and would like to use okta org auth server to mint the tokens, then just the mapping is enough.”

Further, it doesn’t seem like my client is compatible with custom authorization servers, possibly because it’s listed on Okta’s OIN?

If I check /.well-known/openid-configuration for the Okta org server, with my clientID, I do see that my custom attributes are included in supported_claims.

However, when calling /userinfo, the custom attributes are not returned.

Just to clarify, you can’t use custom authorization servers with OIN apps.

Note: To support the potentially large numbers of Okta orgs accessing it through the OIN, an OIDC integration can’t use a custom authorization server, including the default server.