Describe the issue:
When an application is using a custom grant to do a token exchange, the first token is obtained from a particular IDP and then it is exchanged for another token from another IDP using a token service.
As of now, the SDK initiates a refresh token call whenever a 401 response is received to a network call and gets a new token from the first IDP.
The issue is that although the token from the first IDP is obtained from the refresh token grant, the token exchange with the second IDP doesn't happen and hence, the access token stored in the worker is the token from the first IDP and all other network calls to the backend REST APIs fail since they are expecting a new token from the second IDP.
How to reproduce:
Expected behavior:
When the SDK refreshes a token, it would be expected to see if a custom grant has been configured and if so, initiates the custom grant as well.
Environment information (Please complete the following information; remove any unnecessary fields) :
Describe the issue: When an application is using a custom grant to do a token exchange, the first token is obtained from a particular IDP and then it is exchanged for another token from another IDP using a token service.
As of now, the SDK initiates a refresh token call whenever a 401 response is received to a network call and gets a new token from the first IDP. The issue is that although the token from the first IDP is obtained from the refresh token grant, the token exchange with the second IDP doesn't happen and hence, the access token stored in the worker is the token from the first IDP and all other network calls to the backend REST APIs fail since they are expecting a new token from the second IDP.
How to reproduce:
Expected behavior: When the SDK refreshes a token, it would be expected to see if a custom grant has been configured and if so, initiates the custom grant as well.
Environment information (Please complete the following information; remove any unnecessary fields) :
Optional Fields
Related issues:
Suggested labels: