OIDC - Validation failure during PAR does not trigger OnAuthenticationFailed() event

[bigred8982]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

OpenIdConnectHandler.cs

When a validation failure occurs during a PAR request (ex. the request includes an invalid client_id), an OpenIdConnectProtocolException is thrown. This exception bubbles up as an unhandled middleware exception.

This happens during HandleChallengeAsync(), but that method does not catch this (or any other) exception and call the OnAuthenticationFailed() event.

Expected Behavior

I would expect this type of error to trigger the OnAuthenticationFailed() event so that it can be specifically handled.

Before PAR, the user is redirected to the IDP for login. That redirect request carried with it the client app's configuration (client_id, redirect_uri, etc). If that information was not valid, the IDP itself would handle presentation of the error to the end user.

With PAR, we are moving the validation response handling to the client application.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

9.0.101

Anything else?

No response

[bigred8982]

Would love an opinion from @josephdecock if this is desired behavior.

[halter73]

I'm also interested in @josephdecock's opinion here. My gut is that it should be handled similarly to what we'd do if we got an invalid response from the token or userinfo endpoints. And since HandleRemoteAuthenticateAsync calls into those endpoints in a big try/catch block that turns all exceptions into AuthenticationFailed events, I think we should probably do something similar for PAR requests.

That said, looking a bit deeper at the AuthenticationFailed event, I see that the AuthenticationFailedContext is a HandleRequestContext which doesn't make much sense for error that happen even before redirecting to the identity provider. At that point the OpenIdConnectHandler hasn't handled any requests to "handle" or "skip" or whatever.

We could create a new event, but is that worth it if the only time that event would likely fire is when there's a misconfiguration or the provider is down? Is an event that much easier to deal with than throwing directly out of ChallengeAsync()? And even if we did have an event, wouldn't it be better to continue to throw out of ChallengeAsync() if we can to ensure the error isn't missed?

[bigred8982]

For what it's worth, when using PAR, you are now communicating with the IDP prior to redirecting. You're basically initiating protocol behavior with the IDP at that point, not just gearing up to redirect. It feels like AuthenticationFailed events are appropriate here, even from ChallengeAsync().