New access token already expired

[norgie]

We're using IdentityServer 7.2.3 (communicating with EntraID) and BFF 3.0.0. As part of a lift and shift operation we're using WCF for the communication between a .net 9 based back-end and a .net 4.6.* based back-end. We've successfully implemented token based authentication for this scenario. However, when the client requests data from the 4.6.* based backend (via the BFF and the .net 9 based back-end) the token passed to the old back-end fails validation because it has already expired. E.g. last Monday we discovered that the token received had its expiry date set to Friday 19th of December. This after the client logged in via the BFF-IdSrv-EntraId path and potentially should get a new cookie which I assume forces the BFF to fetch a new access token from our IdSrvr instance.

Can anyone enlighten me to why this happens and what we can do about it to ensure that the token is valid?

TIA

--norgie

[wcabus]

Can you explain a bit more how this setup is designed? For example, how the WCF service is retrieving the access token?

What I can already say, is that the BFF will refresh access tokens for remote APIs when you're accessing them through the BFF, provided that the BFF has access to the offline_access scope to refresh tokens. I'm thinking that the WCF service is not leveraging the functionality of Duende.AccessTokenManagement inside the BFF, which is responsible for refreshing the tokens.

[norgie]

It fails all the time, although I haven't tested it today to see if the token still displays the same behaviour.

I agree with you when it comes to "seconds" but in the original problem we were talking days, i.e. running on a Monday the token's expiry date was the previous Friday.

I'll follow your suggestion as to BackEndA requesting a new token on behalf of the user and see what I can get up and running. Is this best achieved in BackEndA by utilising the Duende.AccessTokenManagement package(s)?

Btw, will this work if the token passed on to BackEndA has already expired?

[AndersAbel]

This section suspicious to me:

if (!string.IsNullOrEmpty(token) && !_channelFactory.Endpoint.EndpointBehaviors.TryGetValue(typeof(BearerTokenBehavior), out var endpointBehavior))
            _channelFactory.Endpoint.EndpointBehaviors.Add(new BearerTokenBehavior(token));

How is _channelFactory defined? What is the lifetime of the _channelFactory? From the if statement it looks like the channel factory might be use multiple times and you want to make sure that you only add the BearerTokenBavior once. But when you add it, you do so with a fixed token value that is then used for as long as the _channelFactory stays alive.

[norgie]

That piece of code was changed after posting the original code and looks like this now:

if (!string.IsNullOrEmpty(token) && !_channelFactory.Endpoint.EndpointBehaviors.TryGetValue(typeof(BearerTokenBehavior), out var tokenBehavior))
{
    _channelFactory.Endpoint.EndpointBehaviors.Remove(tokenBehavior); //Avoid "caching" (expired) tokens
    _channelFactory.Endpoint.EndpointBehaviors.Add(new BearerTokenBehavior(token));
}

_channelFactory is created in the constructor of a class called WcfFacilitator. However, as I pointed out here, the token mentioned in that thread was expired before it reached the code above.

[wcabus]

Could you share the entire setup of your BFF? We're mostly interested in the following parts:

• Any registered services that may alter the default services for Duende.BFF or Duende.AccessTokenManagement
• The configuration of the cookie authentication handler (AddCookies) or any post configuration, especially if you handle specific cookie events, replaced the TicketDataFormat or SessionStore, ...

The more you're willing to share from your BFF service registration and configuration, the better. Of course, do obfuscate or omit any client IDs, client secrets, etc.

[norgie]

We've suspected that the error might be caused by a case of PEBKAC. After getting a second pair of eyes to look at the code we now suspect that it is caused by a lifetime misconfiguration of the services that news up our WcfFacilitator, i.e. they were registered as Singleton while they most likely need to register as Transient. So we changed the container lifetime for these services and so far things look ok. I won't conclude yet that the issue has been solved as I will monitor the app until next Monday. I'll get back to you then if the problem persist. Thanks for all feedback so far.

[norgie]

https://github.com/orgs/DuendeSoftware/discussions/460

The qstn still stands