search

asgardeo / asgardeo-auth-react-sdk

To maintain the implementation of Asgardeo React authentication SDK
Apache License 2.0
40 stars 91 forks source link

Manage both `id_token` and `access_token` during httpRequest #212

Open greg-pendlebury opened 9 months ago

greg-pendlebury commented 9 months ago

Is your feature request related to a problem? Please describe. Yes. We want to switch to this library to use httpRequest() to manage tokens for us. It appears to work ok in most scenarios and we think we've got it working the way it is currently intended to:

  1. httpRequest() automatically manages access_token and includes it for bearer authorization to get through our WSO2 APIM layer.
  2. We use HttpRequestConfig object to pass the id_token to the backend system in the X-JWT-Assertion header.

I believe the problem arises because after the config with the id_token is passed in, the first service call can possible fail with 401/403 issues and the library goes through a refresh loop and re-attempts. The re-attempt will update the access_token in the managed part of the call, but won't touch the id_token passed in through config, resulting in them being misaligned.

We are still exploring all of our options, but currently looks like httpRequest() is not suitable for our needs because it can only manage one token, so we will have to continue manage tokens with custom code outside the library... undermining why we wanted to use the library over our older custom login code.

Describe the solution you would prefer If the config for httpRequest() exposed a parameter like idTokenHeader we could provide X-JWT-Assertion and the second attempted call could update both together.

Additional context I think we're aligned with advice from https://github.com/asgardeo/asgardeo-auth-react-sdk/issues/79 ... but I could be wrong. I pinged a different team on the idea of using the id_token to get through APIM, instead of the access_token... but I don't have control that system.

Beyond that, switching approach now would need every other client that passes through APIM to change their token handling.

pavinduLakshan commented 9 months ago

The re-attempt will update the access_token in the managed part of the call, but won't touch the id_token passed in through config, resulting in them being misaligned.

I assume that the reason for not touching the ID token is that ID token remains mostly static (because ID token contains user info which doesn't change frequently) and therefore rarely needs to be updated everytime the access token is updated.