AddIdentityApiEndpoints breaks Blazor's RedirectToLogin behavior.

[los93sol]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I have a Blazor app that uses .NET Identity. The same app has a SignalR hub and I need to support both Bearer and Cookies auth so I started with a template project and configured Identity with builder.Services.AddIdentityApiEndpoints to get both schemes registered and the forward handler. This works for the most part, but it breaks Blazor's RedirectToLogin component. If you navigate to the Index page first, then click the Auth link it works properly and you are redirected to login as you would expect, but if the user has a link straight to the /auth page, they receive a 401 and are not properly routed through Blazor. This seems very unexpected as the guidance previously has been to use Bearer for SignalR, and Cookies for web interface. Is this a known thing or is there an example of how to do this properly.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

[MackinnonBuck]

Thanks for reaching out, @los93sol.

Is there a reason you're not using cookie-only authentication? If your scenario is totally browser-based (i.e., there's not a native client), that's what we would recommend. We expect that this will exhibit the behavior you're expecting.

See also:

• https://learn.microsoft.com/aspnet/core/signalr/authn-and-authz#cookies-vs-bearer-tokens
• https://learn.microsoft.com/aspnet/core/blazor/fundamentals/signalr#client-side-signalr-cross-origin-negotiation-for-authentication
• https://learn.microsoft.com/dotnet/api/microsoft.aspnetcore.authentication.cookies.cookieauthenticationoptions.loginpath

[los93sol]

I’m not using cookies only because there are remote headless workers that need to connect to the hub as well. Per the documentation Bearer is the recommended approach in this scenario.

[los93sol]

I added .AllowAnonymous(); at the end of MapRazorComponents() and that resolves the unexpected behavior with Blazor when components have Authorize attributes on them and allows Routes.razor to handle those as normal, but that issue seems like a massive oversight in the template and one that cost me 2 days troubleshooting.

Now the issue I’m facing is I want the API side, including SignalR to return 404 instead of 403’s and a catch all for everything that’s not a blazor route to return 401 for unauthenticated users as well. The idea here is to prevent information disclosure about endpoints that exist but users do not have access to

[mkArtakMSFT]

What you're trying to achieve should be doable. I'm going to turn this issue into a Doc item for us to improve the documentation later. In the meantime, hopefully somebody from the community will be able to help you out here.

[halter73]

#9039 is related and discusses how customize OnRedirectToLogin and OnRedirectToAccessDenied for the cookie handler.

If you need more flexibility to select which handler to use for which requests/operations, you might want to use a policy scheme.

[los93sol]

I was able to achieve it with the following....

Note here that I can't use the constant to get at it and the lack of an override with an action to configure it directly is what made getting at this unclear in the first place.

builder.Services.Configure<AuthenticationSchemeOptions>("Identity.BearerAndApplication", options =>
{
    // Let the OnRedirectToAccessDenied Event in ConfigureApplicationCookie handle the response for 403's
    options.ForwardForbid = IdentityConstants.ApplicationScheme;
});

builder.Services.ConfigureApplicationCookie(options =>
{
    options.Events.OnRedirectToAccessDenied = context =>
    {
        context.Response.StatusCode = StatusCodes.Status404NotFound;
        return Task.CompletedTask;
    };
});

[los93sol]

The last thing I'm looking at is how an ITicketStore can be used with the BearerToken auth to move the state from the token to the server like how it can be done with Cookies. I see that BearerTokenOptions do not have an option to set it and the BearerTokenHandler does not implement it anyway so I'm looking for some method that this could be achieved as well.

[mikekistler]

We believe that the question you've raised have been answered. If you still feel a need to continue the discussion, feel free to reopen it and add your comments.