How to make an app with multiple permission levels?

Thanks for the clarification. So I think I’ve got a few remaining specific questions:

  1. Is it possible to pass custom attributes via an OIN app and /userinfo using the Okta org authorization server? If so, how exactly?

  2. Are custom attribute values in /userinfo based on their value on the app user profile or the Okta user profile?

  3. Is it possible for an OIN app to automatically create specific custom attributes on the app user profile upon install? Or will each installer need to manually set these up?

Even if you can only answer 1-2 of these questions, it’d be incredibly helpful. Thanks!

Here’s a screenshot from my default authorisation server config when adding a new claim. If you compare it to my earlier screenshot, you’ll see it’s missing the /userinfo option for the claim.

Looks like you can only get custom claims in the access / ID tokens with the default auth server.

Just to clarify are you writing this application which has been submitted to the OIN, or is it from a 3rd party? If this is an app you control (and the OIN submission process) it seems you can specify a series of variables to be passed through (Configure protocol-specific settings | Okta Developer)

Here’s my stab at your latest questions:

  1. Is it possible to pass custom attributes via an OIN app and /userinfo using the Okta org authorization server? If so, how exactly?
    What it really boils down to is how the OIN app is expecting to get or receive data from Okta. the app will be coded to look for certain claim names, variables, scope names and / or use /userinfo. Back to your first message, do you know which claim or variable is used to pass the role-type to the app?

  2. Are custom attribute values in /userinfo based on their value on the app user profile or the Okta user profile?
    The app user profile is the mechanism Okta has to support an override / extension of the attributes in the user profile. This is generally the layer you get to do things like rewrite the username or add app-specific claims. Claim values are pulled from the user profile if there’s nothing special set in the app suer profile. When you configure custom claims in the auth server, you can specify either as an attribute source.

  3. Is it possible for an OIN app to automatically create specific custom attributes on the app user profile upon install? Or will each installer need to manually set these up?
    Not 100% sure here, but when you add the OIN app to your Okta org it will do its default thing. You would then customise the app profile with additional schema / tranformations I believe.
    If you control the OIN app and its submission process, there’s variables you can specify.

Cheers,
Adrian

Hi Adrian, thanks for your response!

Just to clarify are you writing this application which has been submitted to the OIN, or is it from a 3rd party? If this is an app you control (and the OIN submission process) it seems you can specify a series of variables to be passed through (Configure protocol-specific settings | Okta Developer)

This app is published on the OIN, and it’s our app (Canny | Okta). We’re trying to enhance it by supporting authentication into multiple roles rather than just a single role.

It looks like those variables are sent during the initiate/complete flow, which I don’t think is what we’re looking for. Those are install-wide values, not something like custom attributes that can be set per user/group.

Back to your first message, do you know which claim or variable is used to pass the role-type to the app?

I do know which claim/variable we’re looking for. We’re basically trying to add a custom attribute, on the app user profile, called cannyRole.

I have been able to successfully set this up if I install the app from scratch, use a custom authorization server, and add the claim to that authorization server. But that’s a lot of friction for our customers. It means they can’t use our app in the OIN…

If we can get all this done using the Okta org authorization server and let customers continue to use our OIN app that’d be ideal. It seems like it should be possible based on this article (Okta Help Center (Lightning)), but I just can’t get it to work.

I think I’m almost out of ideas here. The OIN specific documentation on developer.okta.com is fairly light on. My interpretation is that they expect the customer using your app to have to do some config.

I don’t suppose there’s a way to reach the Okta OIN team now that you’vre ‘in’ and ask them if they have any further guidance?

Manual config from a guide is a bit of friction, but talking from my experience as an Okta admin, I got fairly used to configuring each app to its own special, requirements.

An outside option could be to write a script which will autoconfigure your app using the Okta API. Customer plugs in an API key and away they go.

Sure, it just seems crazy to me that Okta is this company that’s built specifically for authenticating users into things, and I can’t accomplish this very simple thing (mapping Okta groups to roles) with our app on Okta’s app store. Instead I have to ask our (mutual) customers to create apps and authorization servers and custom attributes from scratch… It’s just such a bad experience and so much friction.

And it seems like from a few articles on Okta’s help center, it should be possible to get custom attributes from id_token or userinfo using an OIN app and the Okta org auth server… But I just can’t for the life of me figure out how to actually do that.

How can I get in touch with the OIN team? Is there an email address?

Yep, it’s crazy that at least the base config can’t be automated to make it easy for customers. There will always be some finessing required as each Customer’s environment can be a little unique (different attribute names, different groups), but that should be some last mile config.

I assumed that the OIN submission portal would have a way to contact the OIN team? I haven’t done it myself.

After you submit your app to the OIN, a member of our OIN team will reach out to discuss your submission and work with you to test it.

1 Like