ASP.NET Core 8 Identity Endpoints not compatible with FallbackPolicy that requires authenticated users by default

[SaebAmini]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Currently, the recommended way to require authenticated users by default on all routes seems to be setting the fallback policy:

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = new AuthorizationPolicyBuilder()
        .RequireAuthenticatedUser()
        .Build();
});

With .NET 8's new Identity features, you can add a bunch of endpoints via app.MapIdentityApi<MyUser>();.

However, the endpoints that are supposed to be anonymous (like /register and /login) don't work correctly with the above fallback policy, because (I'm assuming) they somehow get the fallback policy applied as well, which looks like a bug to me.

Here's an example of a register call that results in an infinite redirect loop:

> POST /register HTTP/1.1
> Host: localhost:7100
> Content-Type: application/json
> Accept: */*
> Content-Length: 54

| {
|   "email": "foo@bar.com",
|   "password": "***********"
| }

< HTTP/1.1 302 Found
< Content-Length: 0
< Date: Thu, 18 Jul 2024 21:53:11 GMT
< Server: Kestrel
< Location: http://localhost:7100/Account/Login?ReturnUrl=%2Fregister


> GET /Account/Login?ReturnUrl=%2Fregister HTTP/1.1
> Host: localhost:7100
> Content-Type: application/json
> Accept: */*

< HTTP/1.1 302 Found
< Content-Length: 0
< Date: Thu, 18 Jul 2024 21:53:11 GMT
< Server: Kestrel
< Location: http://localhost:7100/Account/Login?ReturnUrl=%2FAccount%2FLogin%3FReturnUrl%3D%252Fapi%252Faccount%252Fregister


> GET /Account/Login?ReturnUrl=%2FAccount%2FLogin%3FReturnUrl%3D%252Fapi%252Faccount%252Fregister HTTP/1.1
> Host: localhost:7100
> Content-Type: application/json
> Accept: */*

< HTTP/1.1 302 Found
< Content-Length: 0
< Date: Thu, 18 Jul 2024 21:53:11 GMT
< Server: Kestrel
< Location: http://localhost:7100/Account/Login?ReturnUrl=%2FAccount%2FLogin%3FReturnUrl%3D%252FAccount%252FLogin%253FReturnUrl%253D%25252Fapi%25252Faccount%25252Fregister


> GET /Account/Login?ReturnUrl=%2FAccount%2FLogin%3FReturnUrl%3D%252FAccount%252FLogin%253FReturnUrl%253D%25252Fapi%25252Faccount%25252Fregister HTTP/1.1
> Host: localhost:7100
> Content-Type: application/json
> Accept: */*

< HTTP/1.1 302 Found
< Content-Length: 0
< Date: Thu, 18 Jul 2024 21:53:11 GMT
< Server: Kestrel
< Location: http://localhost:7100/Account/Login?ReturnUrl=%2FAccount%2FLogin%3FReturnUrl%3D%252FAccount%252FLogin%253FReturnUrl%253D%25252FAccount%25252FLogin%25253FReturnUrl%25253D%2525252Fapi%2525252Faccount%2525252Fregister

A workaround could be exposing a mechanism to have more control over the generated endpoints and to possibly apply [AllowAnonymous] to them, but I couldn't find anything to that effect, which has practically blocked me from using the above two features together.

Expected Behavior

The generated identity endpoints that are supposed to be accessible anonymously, such as /register, have [AllowAnonymous] applied to them so they don't follow the fallback policy.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

8.0.202

Anything else?

ASP.NET Core 8, following https://devblogs.microsoft.com/dotnet/whats-new-with-identity-in-dotnet-8

[jacob7395]

Did you try;

app.MapIdentityApi<>().AllowAnonymous();

It might not map as expected in this use case.