Token Exchange setting incorrect clientId

Describe the bug

I’m attempting to do an internal-to-internal token exchange. The exchange returns successfully, but it appears that the issuedFor or azp claim is set to the incorrect client.

This poses a problem in that the exchanged token is not able to be refreshed with its access token because the refresh token is bound to the wrong client.

I’m exchanging the token so that I can get the scopes, etc from the target client. That works great here, but I then need to be able to use the refresh token to exchange it for a new access token that has those same scopes. In the current state, I instead have to re-initiate the token exchange all over again.

I’m I understanding token exchange correctly here? I took it that you take a token from client A and are able to completely exchange it for a token from client B. The way this is currently set up, the token is exchanged for another client A token, but that has been enriched with scopes from client B. Also, why is no identity token returned from the exchange?

Version

15.0.2

Expected behavior

The Access Token and Refresh token should have the azp set to the target client.

Actual behavior

The Access Token and Refresh token are set to the starting client.

How to Reproduce?

To reproduce, simply follow the internal-to-internal token exchange docs and inspect the tokens that are returned. The azp will be set to the starting client.

Once the tokens have been exchanged, attempt to issue a refresh against the target-client.

POST /realms/:realm/protocol/openid-connect/token

grant_type: refresh_token
refresh_token: <token>
client_id: target-client

Response:

{
    "error": "invalid_grant",
    "error_description": "Invalid refresh token. Token client and authorized client don't match"
}

This makes sense given the azp is for the starting-client, not the target.

Anything else?

• responseBuilder.getAccessToken().issuedfor(client.getClientId());
• responseBuilder.getRefreshToken().issuedFor(client.getClientId();

[pedroigor]

Allowing public clients to exchange tokens opens security holes and that is the reason behind the last updates we did in this area. Conceptually, it is also wrong because a public client is conceptually a client and not a resource server.

You might consider looking at some SPA architectures in this specification. In particular, the first one is related to both SPA and API living within the same domain.

Another possible approach is to provide your own custom TokenExchangeProvider implementation so that you can support your legacy system as an additional subject token type.

[nickzelei]

Preface: I no longer work at the company where I was utilizing this technology.

But the setup was such that we had two clients that we would authenticate clients through. The first (or starting) client was used to do the initial authentication. Then we would perform a token swap to the second client based on the company account the user was operating under. This would swap out the token and give them more specific scopes that was appropriate for the account they were acting as.

I assumed the token exchange was a true exchange such that it was as if the user fully authenticated through the target client, not just swapped.

But it seems to me that the swapped token is still bound in some way to the original authenticated client. This makes the refresh logic a bit more complex because the original token doesn’t become throw away such that we have to continually issue another swap once the swapped token expires.