AuthorizationMessageHandler fails to set authenticationstate on error

[davhdavh]

Describe the bug

If _provider.RequestAccessToken is unable to provide a valid token, the IAccessTokenProvider API assumes that the RedirectUri is followed and the authentication flow reapplied. However, the AuthorizationMessageHandler class throws an exception because it cannot handle that flow.
It should however also inform IAccessTokenProvider that the current AuthenticationState is no longer valid.

Further technical details

.Net 6.0 preview 2

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[TanayParikh]

Hi @davhdavh. We made some changes in the RC2 .NET 6 release which may resolve this. Could you see if you're still encountering this issue with the Release/6.0.1XX-rc2 in https://github.com/dotnet/installer#installers-and-binaries.

If so, do you happen to have repro steps, or a basic repro repository I can try out?

However, the AuthorizationMessageHandler class throws an exception because it cannot handle that flow.

What's the exception?

[davhdavh]

Hi @TanayParikh
That change solves the reverse problem (That AuthorizationMessageHandler didnt know the token was invalidated), whereas this bug is that AuthorizationMessageHandler doesn't inform _provider that the token is invalid (when it throws AccessTokenNotAvailableException) and that _provider doesn't tell itself that the token is invalid if RequestAccessToken fails to return a valid token.
Like I was trying to say in #30929 it occurs when the token expired AND the token refresh time expired, because the AuthorizationMessageHandler is the only check that the token is still valid and that is only called when it is used and doesn't refresh based on the expiration datetime. For example, if someone left your site open overnight without doing anything.

[TanayParikh]

It should however also inform IAccessTokenProvider that the current AuthenticationState is no longer valid.

whereas this bug is that AuthorizationMessageHandler doesn't inform _provider that the token is invalid

Not sure what you mean by this. The IAccessTokenProvider doesn't explicitly track the authentication state.

The AccessTokenNotAvailableException exception thrown in this case needs to be caught by user code, the current state saved, and the user subsequently redirected to re-authenticate. Closing this as by design.

[davhdavh]

The IAccessTokenProvider doesn't explicitly track the authentication state.

Correct, the problem is not inside AuthorizationMessageHandler. However, it does call _provider.RequestAccessToken. This is actually implemented in a class that DOES track authentication state, namely the AuthenticationStateProvider.

The bug is that when RequestAccessToken fails inside AuthenticationStateProvider, it itself should detect that the authentication state is no longer valid so that code that depends on the AuthenticationStateProvider (which would be ALL default code in everyones projects) can inform the user that they were logged out.

[TanayParikh]

so that code that depends on the AuthenticationStateProvider (which would be ALL default code in everyones projects) can inform the user that they were logged out.

As I mentioned above:

The AccessTokenNotAvailableException exception thrown in this case needs to be caught by user code, the current state saved, and the user subsequently redirected to re-authenticate.

Hence, by catching the AccessTokenNotAvailableException, you can inform the user they were logged out.

If you don't feel that this sufficiently resolves the issue you're facing, feel free to put up a PR with your suggested change (I'm assuming this would be a minor change, let me know if not), and we'll evaluate accordingly whether the change would be appropriate for the framework.