We are looking to utilize the token exchange flow for communications using access tokens from two different internal UI clients, which both have 2 separate Authorization Servers. App/AuthServer1 and App/AuthServer2
I can achieve generating an access token using the token exchange grant.
App1 signs the user in as normal via authorization code flow in App1/AuthServer1
App1 access token is exchanged via using an Okta API service application for a token from AuthServer2.
The issue is, both Auth Servers have different Audiences, and a token generated using this flow will have the Audience of AuthServer1, which is incompatible with all our backend API services secured by AuthServer2.
Ideally, when the AuthServer1 token is exchanged via AuthServer2 and it is enriched with the AuthServer2 Audience.
Is there a recommended/possible approach to deal with this scenario, opposed to adding compatibility to the individual API apps or changing the audiences to be consistent across AuthServers?
Hi,
I may be wrong, yet it seems to me that in the token exchange flow, the audience is the second auth server that trusts the first one. In your case, it means that when the token is exchanged, the audience to set in the POST is the AuthServer2, not the AuthServer1.
Generate token via auth code flow from AuthServer1
Post to the AuthServer2 /token endpoint using token exchange flow along with the client id/secret of a Okta API Service app which has been added to a policy in AuthServer2.
AuthServer2 trusts AuthServer1
The tokens can call AuthServer2 fine this way.
Perhaps i have been reading the documentation the wrong way round. Thanks for the nudge in the right direction. In practice the Audience has changed from api://authserver1 to api://authserver2. But having to add a AuthServer1 Okta API Service app to the AuthServer2 policies feels a bit like iām mixing boundaries.