I’m developing an application with a MicroServices architecture and I think I am having some confusion about how my Okta should be configured.
I have a front-end application which uses OIDC to authenticate the user. This works correctly and the user is able to log in and receives a cookie with the access_token and identity_token.
The next part is what I’m having trouble with. In the API management documentation, it says that “API Products” should each have their own authorization server so I have created different ones to represent those which each define their own issuer and audience. I had intended to send the users original access_token to the services which each call to make sure that the user is authorized to perform an action at each service call but because the Issuer and Audience don’t match the original token, I receive an unauthorized response.
Am I using API management incorrectly or is there some way I can take the users token and fetch one specific to each authorization server?
Audience is useful for when you need an access token to be siloed. For example, if you have two different APIs and the scopes dont make any sense at all, you would think about this as siloing by audience.
For example, if I’m building 2 applications that are supported by 2 separate sets of APIs, each with their own policies and scopes, I would set up two authorization servers.
An example of this, the access token for Google API vs Google Cloud Platform API would have access tokens with two totally separate audiences. Even though they have the same login. The scopes and policies on what you are allowed to do are totally different.
Now if you look at Google API, it has the same audience and issuer, but what you are allowed to do with the access token is scoped based on consent, but the access token will get different scopes.
It sounds like what you want to do is have one authorization server with a set of scopes, this will make sure your client app doesn’t need to manage a bunch of access tokens. Very similarly, if I built a client app that was making it easy to read emails and create docs in drive automatically, I would be working with one access token, not two.
Hope this makes sense, let me know any questions,
Tom
Thanks for the response Tom! I think I understand the proper flow now. So I guess my next question is, if I am calling an API that uses a separate authorization server than what my access token is currently for, would I be able to take my identity/access token and exchange that for an access token for that specific audience?
I believe Token Exchange that is in this blog post is the functionality I would need? If so, is there an endpoint I could use to do so?
Token exchange is something that is currently on our roadmap, unsure on the timing. I would open of a case with developers@okta.com so you can track it.
As a workaround, you could get another access token if the session is still valid in Okta by doing a prompt=none with the authorize url.