aspnetcore
aspnetcore copied to clipboard
59462 OIDC par failure
Add OIDC event to allow caller to react to OIDC PAR failure during challenge phase
Description
Add new OIDC OnPushAuthorizationFailed, new context for this event, logic to fire event, tests.
Problem
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.
Please see issue #59462 for slightly more details.
Goal
We need to give the application the ability to handle the response when a PAR request fails during the challenge phase. Since an exception during the challenge phase bubbles up as a middleware exception, it is difficult for the application to respond. By including a specific OIDC event, the application has the opportunity to redirect the browser to a user-friendly error page.
Example of a web app utilizing this new feature
builder.Services.AddAuthentication(...)
.AddOpenIdConnect("oidc", options =>
{
...
options.Events.OnPushAuthorizationFailed = (ctx) => {
var logger = ctx.HttpContext.RequestServices.GetRequiredService<ILogger<Program>>();
logger.LogError(ctx.Exception, "Received error while sending PAR request.");
ctx.Response.Redirect("FriendlyErrorPage");
ctx.Handled = true;
return Task.CompletedTask;
};
});
Fixes #59462
@dotnet-policy-service agree company="Tyler Technologies"
Would love feedback from @josephdecock
Also, I'm not sure if this should go into main, but I'd like to see it show up in at least the 10.0 release (it's probably too late to get it into 9).
If there anything else I need to do process-wise to make this PR ready for review, please let me know. This is my first contribution and I might have accidentally missed a step.
/azp run
Commenter does not have sufficient privileges for PR 61947 in repo dotnet/aspnetcore
Sorry for a hugely delayed response on this thread!
I really like this idea and the PR. It's good that if the error isn't handled, the exception still bubbles up, but if you want to handle it you can. I think this approach of a separate event for pushed authorization is also the best thing to do, because the existing AuthenticationFailed event would happen at a very different point in the protocol interaction. All in all, I think this is a great improvement, and I hope it lands in .NET 10.
@halter73 Got feedback and a thumbs up from an expert! Is there anything I can do on my end to help get this through?