AddDefaultAccessTokenResiliency in AccessTokenManagement 4 question

[ArturDorochowicz]

Hi

I noticed that in AccessTokenManagement 4 in the implementation of AddClientCredentialsHttpClient there's a new call to AddDefaultAccessTokenResiliency (I think it's new, correct me if this had existed earlier).

But I won't always use AddClientCredentialsHttpClient. For example, if I want to configure a typed http client, I will use AddHttpClient(...).AddClientCredentialsTokenHandler(). That invocation won't have AddDefaultAccessTokenResiliency unless I remember to add it myself.

So my question is 1) how important that AddDefaultAccessTokenResiliency is? Is it required for the protocol to work? Or is it nice to have? What am I losing if I don't add it? The documentation does not seem to mention anything about it.

And 2) the documentation page here https://docs.duendesoftware.com/accesstokenmanagement/workers/#automatic-token-management-using-http-factory shows a typed client configuration without resiliency and has this note:

The clients in the HTTP client factory have a message handler attached to them that automatically retries the request in case of a 401 response code. The request gets sent again with a newly requested access token. If this still results in a 401, the response is returned to the caller.

Is this note true without AddDefaultAccessTokenResiliency?

[wcabus]

When you use AddClientCredentialsTokenHandler(), then you will indeed not have the benefits of AddDefaultAccessTokenResiliency() which is included when you would use AddClientCredentialsHttpClient() instead.

You can however include both HTTP message handlers when registering your own HTTP client:

services.AddHttpClient<CatalogClient>(client =>
{
    client.BaseAddress = new Uri("https://apis.company.com/catalog/");
})
    .AddDefaultAccessTokenResiliency()
    .AddClientCredentialsTokenHandler(ClientCredentialsClientName.Parse("catalog.client"));

The resiliency handler is not required for the protocol to work, but it adds a retry when you encounter a 401 Unauthorized response. This can be useful if you use DPoP, because you may get an error in that case requiring you to retry the same request by echoing back a nonce send by the server. In some cases, it can also be useful to have a retry in place to refresh an access token.

The note on our documentation page only applies when the default resiliency handler has been configured. We will update the documentation to be more specific.

[ArturDorochowicz]

Thank you.

Can you elaborate what the behavior was in ATM 3?
Did code like this have retries for 401 (i.e., the retry logic was in the token handler)

services.AddHttpClient<CatalogClient>(client =>
{
    client.BaseAddress = new Uri("https://apis.company.com/catalog/");
})
    .AddClientCredentialsTokenHandler("catalog.client");

[wcabus]

In v3, the retry logic was part of the ClientCredentialsTokenHandler, or to be more precise, it's base class AccessTokenHandler. In v4, the decision was made to restructure a lot of the codebase, which lead to moving specific logic into separate classes, such as the resiliency handler.