User Claims missing from Identity Endpoints breaks Authorization

[augustevn]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I did some digging, it seems like the user Claims are no longer returned from /manage/info from the .MapIdentityApi<User>().

My custom authorization was depending on getting those claims.
This change broke my app, worked in RC2 not in RTM. Or is this intentional?

IdentityApiEndpointRouteBuilderExtensions.cs, line 455:

    private static async Task<InfoResponse> CreateInfoResponseAsync<TUser>(TUser user, UserManager<TUser> userManager)
        where TUser : class
    {
        return new()
        {
            Email = await userManager.GetEmailAsync(user) ?? throw new NotSupportedException("Users must have an email."),
            IsEmailConfirmed = await userManager.IsEmailConfirmedAsync(user),
        };
    }

Expected Behavior

Return the user's Claims on authenticated GET call to /manage/info on the Identity Endpoints.

Steps To Reproduce

Upgrade from .NET 8 RC2 to .NET 8 RTM, implement the .MapIdentityApi<User>(), spot the 7 differences.

Exceptions (if any)

/

.NET Version

8.0.100

Anything else?

Possibly related to Blazor Identity UI issues: #52063
Of which it likely affects authorization.

[Tratcher]

Yes, this was by design: #51177

[augustevn]

@Tratcher How do you suggest Identity API consumers to handle authorization than, if they can't access the claims? For stateless bearer token auth. Or can Blazor (WASM)'s AuthenticationStateProvider decode that from the token somehow? Which would be a worse practice considering the implictions of that.

[Tratcher]

Authorization must always be done on the server side (where you have access to the Claims in the User). Anything done on the client is just for convenience. You can also expose your own endpoints for the API to check for specific permissions.

[augustevn]

@halter73 @MackinnonBuck @mkArtakMSFT @Tratcher
Let me try again, I think the Blazor WASM way of informing our AuthenticationStateProvider of our claims is broken. At least the seamless integration of that with the Identity Endpoints.

The action of removing the claims from the GET /manage/info response, now broke this. I think that was still a better (authenticated) practice than having to verify and decode the bearer token to get the claims? Since that implies worse practices.

Or ... implementing our own custom endpoint to expose the claims... What did you win?

Take the below CustomAuthenticationStateProvider:

public class CustomAuthenticationStateProvider : AuthenticationStateProvider
{
    public override Task<AuthenticationState> GetAuthenticationStateAsync()
    {
        var emptyAuthState = ConstructEmptyAuthState();
        return Task.FromResult(emptyAuthState);
    }

    public void Authenticate(UserInfoResponse currentUser)
    {
        var identity = new ClaimsIdentity(
            currentUser.Claims.Select(c => new Claim(c.Key, c.Value.ToString())), // No longer possible.
            "auth");
        
        var user = new ClaimsPrincipal(identity);
        var authState = new AuthenticationState(user);
        
        NotifyAuthenticationStateChanged(Task.FromResult(authState));
    }

    public void UnsetAuthenticationState()
    {
        var emptyAuthState = ConstructEmptyAuthState();
        
        NotifyAuthenticationStateChanged(Task.FromResult(emptyAuthState));
    }

    private static AuthenticationState ConstructEmptyAuthState()
    {
        var identity = new ClaimsIdentity();
        var user = new ClaimsPrincipal(identity);
        var authState = new AuthenticationState(user);

        return authState;
    }
}

I'm having doubts on how you test and validate these entire authentication flows / scenarios from front to back.
I think it's time to pull your heads out of your back-ends.

---

While you're at it to make this flow viable:

• It's lacking customizability due to DTO usage on /register, /forgotPassword,
  • Prevents passing extra user data to store in database.
  • Prevents passing extra data like a proper redirectUrl not going to the API.
  • How to validate extra passed data?

I don't understand why it would be a good idea to lead the user to your API using the confirmation link in a SPA + API setup that implements these Identity Endpoints.

I agree that I can build custom endpoints to do all of the above but then I might as well build the other endpoints myself...
I appreciate the efforts nonetheless. Could be a cool / time saving feature.