Refresh token on authentication failure using IAuthenticationProvider / IAccessTokenProvider

[AndrewZenith]

Hi,

There seems to be no mechanism to allow to refresh a token if there is an authentication failure.

I would have expected there to be a call to AuthenticateRequestAsync with something in the additionalAuthenticationContext to indicate an authentication failure on the first try.

Am I missing something here?

[baywet]

Hi @AndrewZenith
Thank you for using kiota and for reaching out.

We expect this concern to be handled by the authentication library. For example, in the case of Azure Identity (implemented here) or MSAL (not implemented here) both libraries handle token caching and token refreshing internally.

The name provider might be misleading here, it should most likely have been named "adapter" or something along those lines. The sole responsibility for the implementers it to "relay" or "adapt" the token acquisition to the "other parts of the infrastructure", And we did not design those interfaces to take on more responsibilities.

Let us know if you have any additional comments or questions.

[AndrewZenith]

Hi,

I'm handling both caching and refreshing in the providers, however there are cases where the tokens that have been retrieved can be invalidated by the site. Without being informed that there is an authentication failure there is no way to know to get a new token and update the cache, or to allow for the request to instantly fail when in a resilience pipeline (by returning no token).

In short failure cases are not being efficiently handled.

At present I am using a resilience pipeline around the request, rather than using the Kiota retry mechanism, however I do not have access to the provide in the API Client in the pipeline and so I am having to use the request option information to build a provider correctly and handle it there to get a new token. It's all quite ugly.

[baywet]

Thank you for the additional information.

When that happens, what does the response look like? 401/403 with www-authenticate response header and claims value? or something else?

[AndrewZenith]

Here's an actual response:

:status: 401
content-type: application/json
content-length: 88
date: Mon, 23 Dec 2024 14:02:49 GMT
content-security-policy: default-src 'self'
www-authenticate: Bearer realm="HMRC API Platform"
strict-transport-security: max-age=31536000;
x-cache: Error from cloudfront
via: 1.1 fcae03c70d8abce0dc89e45009008e3a.cloudfront.net (CloudFront)
x-amz-cf-pop: LHR50-P6
x-amz-cf-id: Bj4wqFlkdUhyyWvep8rhpFb-gZ-ek_mzuivMNwUb_cjTTgPPeN3jpg==

{"code": "MISSING_CREDENTIALS", "message": "Authentication information is not provided"}

[AndrewZenith]

Here's the response when authority has been revoked:

:status: 401
content-type: application/json
content-length: 89
date: Mon, 23 Dec 2024 14:09:51 GMT
content-security-policy: default-src 'self'
www-authenticate: Bearer realm="HMRC API Platform"
strict-transport-security: max-age=31536000;
x-cache: Error from cloudfront
via: 1.1 2cc148080cadcb3c2908058528ecd5b6.cloudfront.net (CloudFront)
x-amz-cf-pop: LHR50-P6
x-amz-cf-id: KnYHkoc3Foypbj8p_vAfpxovFOAuKpPfovnHJsVv0uSCkGUtWhq3BA==

{"code": "INVALID_CREDENTIALS", "message": "Invalid Authentication information provided"}

[baywet]

Thanks for the additional information!

In there, what would you need to pass to a subsequent token request?

[AndrewZenith]

Hi,

I'd just need to know that it is as the result of a 401 so that I can attempt to recreate the token if possible. This could fail, an would return a blank string as the token were this the case, and at this point to call should just return the 401 back to the calling request.

[baywet]

Thank you for the additional information.

The request adapter only calls the authentication provider when the response status code is 401 AND when claims are present in the www-authenticate response header.

This is probably a little hacky, but you could build a middleware handler to artificially add claims to the response header when present, so it triggers the behaviour, and you get another call to the authentication provider.

In the future, if we get more customer demand for those scenarios, we'll consider making the evaluation of the request configurable by the application.

Let us know if you have any additional comments or questions.