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:
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?
Or do we need to make a separate application per role?
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!
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.
Can you please clarify how I would get started on setting up the third solution:
How can I “create multiple custom attributes on the app user profile”?
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?
Interestingly, these claims are all included in claims_supported at https://dev-131057.okta.com/.well-known/openid-configuration. Do I need to somehow add additional claims to the openid-configuration? If so, how would I go about doing that?
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?
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 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.
Extract:
“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.”
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.
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.