BFF Token Management

[wantwi]

Which version of Duende BFF are you using?
version 2.0
Which version of .NET are you using?
version 6.0
Describe the bug
When my access token expired for the first, the AddOpenIdConnectAccessTokenManagement detects and subsequently renew and
brings me the data. However, after about 2 to 3 times of renewing my access token, it stops and return null when getting the access token using await HttpContext.GetUserAccessTokenAsync(). What could be the possible cause of this and is there a way I can send a request to get a new token and then retry my request?

To Reproduce
To reproduce this, set the token life time to about 5mins and try making a request after the 5mins.
The request will bring data even though the access token has expired (meaning there was a refreshed token used).
Repeating it for about 2 to 3 calls, the token will now be null and the request will fail.

Expected behavior
I thought since the AddOpenIdConnectAccessTokenManagement manages the access token and refresh token, there should always be a new access token generated after the access token time has expired and the user has not been logout.

Any solution to this?

[josephdecock]

I would take a look at the IdentityServer logs to understand more fully what is going on here. However, my guess of what is happening is that you might have refresh tokens that require rotated (this is the default). If there's ever a network failure or error during the rotation process, you can end up with the old token consumed and no longer usable, but the new token not at the BFF. Happily, you can safely allow reusable refresh tokens to fix this problem. See here.

[AndersAbel]

Do you have any more questions on this or can we go ahead and close the issue?

[wantwi]

Do you have any more questions on this or can we go ahead and close the issue?

I wanted to know if there is a way I can do a retry for new rotated token provided there is a failure before logging out from the app?

[AndersAbel]

The purpose of refresh token rotation is to ensure that a token is only usable once and that the new refresh token is given to the (legitimate) caller that used the first refresh token. This means that there is no way to get the new refresh token if it was lost.

As Joe says, the easiest for BFF-based (or any server side application) is to change to reusable refresh tokens. As long as the client has a client secret, there solution is still perfectly secure even with reusable refresh tokens.