We have numerous SaaS applications where we are planning to use Okta for authentication and authorization.
Each application uses it’s own APIs with API-defined scopes to perform app-specific functions. Additionally, some development groups want to extend their APIs to allow admin users to manage user profiles/group assignment.
Questions:
Does this mean that every single application must authorize itself twice? Once to the custom authorization server (so it can assign it’s own API scopes) and once to the Okta Org Authorization server (to access Okta user management APIs)?
Is there any way to exchange a custom authorization server token for an org authorization server token? This would allow us to exchange the custom auth token for an org auth token at the API layer to make Okta API requests. We would like these to be user-based tokens (i.e. not client credentials) so that Okta can manage the permissions required to update user records.
How do other groups manage this? (i.e. SaaS applications and/or APIs that also perform user management).
These are all external customer-facing SaaS applications and we want to provide customers/applications the ability to manage their own users.
In Okta if you want to make management API calls (users/groups) with an OAuth access_token then that token is required to be minted from the Org authorization server. In order to use the access_token against various management API not only will the access_token need the correct Okta management scopes, the user will need to be part of a management role in Okta which grants them enough permission for the various management calls they will make.
Custom Authorization servers can’t mint tokens with Okta management scopes other then the okta.myaccount.* scopes which can only be used to manage the users own profile.
Okta does support the on-behalf of token exchange which will retain user context in the new access_token. No OpenID scopes can be requested though.
Unfortunately, it appears that the On-Behalf-Of token exchange doesn’t allow exchanging with the Org authorization server, so this doesn’t really help our situation.
Asking applications to authenticate twice (once to a custom authorization server, once to the org authorization server) is a non-starter. Many of our applications use standard libraries for OIDC authentication, which would need to be heavily customized to allow multiple authorization servers to be used.
I guess the fallback is to build the identity management security into our APIs and use an (org-level) client credentials token for Okta user management calls.