Logout fails in token exchange flow with "openid" scope

[vlgunarathne]

Describe the issue: The SDK provides a custom grant and that can be used for a token exchange from an STS after the initial login token is obtained. However, if the user requests the "openid" scope in the custom grant as well, the id_token from the initial login flow would get replaced from the new id_token received from the STS.

The impact of this happens when the user tries to logout. When the logout request is initiated, the id_token that will be sent to the Identity Provider would be the id_token from the STS and hence the logout would fail.

How to reproduce:

• Login from the IDP
• Once the token is obtained, perform a token exchange with "openid" scope included.
• Perform a logout request.

Expected behavior:

Environment information (Please complete the following information; remove any unnecessary fields) :

• Product Version: [e.g., IS 5.10.0, IS 5.9.0]
• OS: [e.g., Windows, Linux, Mac]
• Database: [e.g., MySQL, H2]
• Userstore: [e.g., LDAP, JDBC]

---

Optional Fields

Related issues:

Suggested labels: Priority/High, Bug

[thivi]

Hi @vlgunarathne, Can you bump the version to v0.2.15 and pass an attribute called preventSignOutURLUpdate to the custom request grant config and set it to true and then try?

[vlgunarathne]

Hi @thivi I followed the above steps and tested the flow. The expected flow mentioned in this ticket is working fine. However, it seems to have introduced another issue. We are periodically invoking the IDP session extension endpoint to keep the user's session alive and we read the isk value in the id_token received from Asgardeo. With this implementation, the getDecodedIdToken() returns the STS token and hence we have no access to the identity session key (isk). Would it be possible to have two functions;

• getDecodedIDToken()
• getDecodedExchangedIDToken() to manage both tokens? Or any other approach to solve this issue.

[thivi]

Hi @vlgunarathne,

Since the session gets updated with the exchange grant, we may have to store these two sessions separately to address your issue. Instead, I would recommend getting ID token after authenticating with the IS server using the getIDToken method and persisting in a storage of your choice before performing the token exchange to have access to both ID tokens.