If you login to an application to get an access token in a user identity context i.e. not client credentials grant, can the application access multiple custom authorization servers on the same Okta tenant instant? or should an application only use a single custom authorization server for an Okta tenant (in user identity context)?
For Example, We have two API Products, and scopes for those APIs are defined in different custom Authorization servers.
CustomAuthServer1:
Issuer: https://dev-#####.oktapreview.com/oauth2/aus8zlpy8i8IaiccN0h7
Scopes: team.photos.read team.photos.readwrite team.photos.private
How can an application request an access token (on user behalf) for scopes when users login if they are defined in different custom authorization servers?
According to Okta documentation, we should create one custom authorization server per API product.
"Assign one authorization server per API Product. Doing so allows teams to maintain separate authorization policies and token expiration times while eliminating scope name collisions. "
However, if you follow this practice for each API product then what will happen if the client application is a Mobile App and the mobile app needs to call three APIs (in user context)? How will you get three access tokens in the user context? How will you show the consent screen to user from multiple authorization servers (as part of the OIDC/OAuth.20 PKCE flow)?
We have this same challenge right now. This has actually been slowing down our organization for a bit – we would like to have internal SPAs able to communicate with several shared backend services. Okta’s advice (via the link above) suggests that we should use separate authorization servers, and this makes some sense for operational segregation and risk management, but it’s not clear to us how we can enable browser clients to seamlessly access multiple services with this setup.
We have three possible solutions so far, but all have challenges. The first is to have all applications (client and server) use the same authorization server. This is simple, but does not seem feasible long-term from a risk perspective.
The second solution is to enhance clients to obtain/manage multiple tokens and route requests based on endpoint path, taking advantage of org-wide SSO to obtain tokens without reprompting the user for each authorization server. This adds quite a bit of complexity – clients now need to know each individual issuer and which paths map to it, along with obtaining/managing the tokens for each. We’re not aware of client-side libraries that can handle this.
The third option is a backend-for-frontend authn layer which uses Okta behind the scenes. This in some ways brings us back to square one, though, where individual scopes cannot easily be requested and a single session ultimately has access to all available authorization servers and scopes. This seems the most promising in some ways, but also has a lot of implementation complexity. Would love to see a good solution for this if one exists.
How is this handled? Does anybody else have a nice solution for this?