BlazorWebAppEntraBff endpoints might need updating

[GC-brian-taylor]

I am having an issue when the user credentials are not passing to the webservice,

I have a stack overflow post and the response to my post said I should be using

jwtOptions.Authority = "https://login.microsoftonline.com/{tenantId}/v2.0";

however the sample code states
// Authority format {AUTHORITY} for ME-ID tenant type: https://sts.windows.net/{TENANT ID}

After a bit of searching it looks like the code is using Entra V1 endpoints, should this be updated to V2 endpoints?

I not sure if the advice I been given is correct or not (as neither work), but thought I should raise it incase the end points could be updated to a newer version.

The code sample in question is for BlazorWebAppEntraBff

---

Issue Details

⚠ Do not edit this section. It is required for issue processing.

• Content Source: dotnet/blazor-samples
• GitHub Login: @guardrex

[guardrex]

Hello @GC-brian-taylor .... Can try something for me so we can investigate this further ............

Look at the request going to the web API in browser developer tools and find the bearer token in the Authorization: Bearer {TOKEN} header ... strip off "Bearer{SPACE}" from the {TOKEN} value the so that it's just the token. Decode the token in https://jwt.ms/ and report back what it says for the issuer (iss).

...... OR .... I can do it and report back. I'm buried in another task at the moment, but I can get back to you later today.

[guardrex]

Actually, I'm going to delay the tutorial work that I was doing for a bit. I'm curious now about a mismatch on the endpoints because I see that the Blazor app is using Identity options for the V2-type of URI for the app's authority (i.e., https://login.microsoftonline.com/). I would like to get to the bottom of this quickly and possibly get a pair of PRs in quickly to update the sample and article if needed. I'll report back my findings shortly.

[GC-brian-taylor]

Really appreciate that, thanks.

[guardrex]

Ok ... here we go 😄 ... 📖 time with Uncle 🦖😆 ...

I did manage to get it to work for V2 tokens with one strange caveat that we'll need to include when discussing this with our security guru @halter73 ......

A little backstory on V1 vs. V2 tokens: I had a discussion with Stephen like one or two years ago, maybe longer, on this subject. My recollection of that discussion is that it was decided to stick with V1 tokens. The app (and article descriptions) work with V1 tokens. Admittedly, I probably should've done a better job calling out that V1 tokens are in use and that the Azure portal creates new app registrations with a accessTokenAcceptedVersion/requestedAccessTokenVersion values of null (I just checked and confirmed that that's still the case), which defaults to V1 tokens.

So ... anyway ... yes ... you can use this app and set things up for V2 tokens. Here's what I did, and @halter73 will need to say what's right/wrong about this so that if we call out V2 now I can open an issue to work on the sample apps (there are a few of them) and the articles ...

• In the Azure portal, I went into the manifest of both the app registration (for the BlazorWebAppEntra app) and the web API registration (the MinimalApiJwt project), and I set accessTokenAcceptedVersion (AAD Graph App Manifest) and requestedAccessTokenVersion (Microsoft Graph App Manifest) to 2. Perhaps, it was overkill for me to set that for the app's registration ... not sure on that point ... but it seemed reasonable that if one were going to adopt V2 tokens that they would adopt them everywhere. I do know that you'd at least need to set that for the web API's registration.

• In the web API, I set the Authority to the v2.0 endpoint. Format ...

  jwtOptions.Authority = "https://login.microsoftonline.com/{TENANT ID}/v2.0";
  

• Also in the web API, I validate explicitly (with a slightly strange caveat) ...

  jwtOptions.TokenValidationParameters = new TokenValidationParameters
  {
      ValidateIssuer = true,
      // Ensure the issuer ends with /v2.0 if using the V2 endpoint
      ValidIssuer = "https://login.microsoftonline.com/{TENANT ID}/v2.0",
      ValidateAudience = true,
      ValidAudience = "{WEB API CLIENT ID}",
      ValidateLifetime = true
  };
  

  Strange 👽 caveat there: It required me to state the audience as just the client id of the web API. If the audience is set as https://{ORGANIZATION}.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555, it 💥 and says that it doesn't match 11112222-bbbb-3333-cccc-4444dddd5555. Therefore, I just stuck the naked client id there as the value. Perhaps, @halter73 knows why.

Now, it works with the V2 authority.

BTW ... You said you were having trouble even with the V1 token. That's likely due to some other misconfiguration that you have. AFAICT here, the apps work as described with V1 ... and now also with V2 using the approach that I've laid out ☝️.

Last I heard, @halter73 was OOF for a bit ... a few days perhaps ... let's let him get back, and then I can email him if he doesn't see the ping here.

If he decides that we should do any of the following, then we can leave this issue open here for the sample updates with a new issue (that I'll open) for the article updates ...

• At least the article (and perhaps code comments here) should state everything is resting on V1.
• Cover V2 as only a section in the article, explaining how to configure for it, or change over to V2 now for all samples and articles ... and if we do that, possibly include a section on how to downgrade to V1.

WRT to troubleshooting your app for V1, check everything. Usually, a dev will find one little thing wrong somewhere in their Azure portal config or in their projects' configs.

Also asking @halter73 about ...

• In the web API config for TokenValidationParameters, why is the ValidAudience just the client id and not the full audience passed to jwtOptions.Audience?

• Is there anything we can do in ServerWeatherForcaster to help devs troubleshoot the issuer (iss) that await downstreamApi.CallApiForUserAsync is going to use? We can't give them ...

  response.RequestMessage?.Headers.TryGetValues("Authorization", out var authHeaderValues)

  ... because the call will fail on a 401 (e.g., invalid token due to an invalid issuer or anything else), throwing an exception that prevents finding out what the issuer is. That would work fine for a working call, but that's not helpful when CallApiForUserAsync goes 💥 on you, and you would like to see the decoded token in jwt.ms. What's the best way to get the token out of the Microsoft.Identity API for troubleshooting?

[guardrex]

I opened and issue and PR to cover this, and I made improvements to the code comments in the sample apps.

On the sample side, this is merely fixed by #655.

On the article side, I'm adding a section. Keep an 👁️ on dotnet/AspNetCore.Docs#36979.

Closing here, and we'll take up further discussion on the PR. Thanks for the issue!

[GC-brian-taylor]

Hi,
Just an update, finally got it to work (using V1)

"Strange 👽 caveat there: It required me to state the audience as just the client id of the web API. If the audience is set as https://{ORGANIZATION}.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555, it 💥 and says that it doesn't match 11112222-bbbb-3333-cccc-4444dddd5555. Therefore, I just stuck the naked client id there as the value."

Have similar but not identical issue docs said to use "api://11112222-bbbb-3333-cccc-4444dddd5555" but I had to remove "api://"
Docs at https://learn.microsoft.com/en-us/aspnet/core/blazor/security/blazor-web-app-with-entra?view=aspnetcore-10.0&pivots=without-yarp-and-aspire#configure-the-backend-web-api-project-minimalapijwt-1

Another issue in the doc is it said to use "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee" but I had to add a "/" at the end

[GC-brian-taylor]

Is there anything we can do in ServerWeatherForcaster to help devs troubleshoot the issuer (iss) that await downstreamApi.CallApiForUserAsync is going to use?

This is what I used

using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.AspNetCore.Components.Forms;
using Microsoft.Extensions.Options;
using System.Security.Claims;

var builder = WebApplication.CreateBuilder(args);

string ReadConfig(string key) => builder.Configuration[$"AzureAd:{key}"] ?? throw new Exception($"{key} not set");
string TenantID = ReadConfig("TenantId");
string WebAPIAppClientID = ReadConfig("WebAPIAppClientID");

builder.Services.AddAuthentication()
    .AddJwtBearer("Bearer", jwtOptions =>
    {
        jwtOptions.Authority = $"https://sts.windows.net/{TenantID}/";
        jwtOptions.Audience = WebAPIAppClientID;

        /*
        jwtOptions.Events = new JwtBearerEvents
        {
            OnAuthenticationFailed = context =>
            {
                Console.WriteLine($"Authentication failed: {context.Exception.Message}");
                return Task.CompletedTask;
            },
            OnTokenValidated = context =>
            {
                Console.WriteLine("Token validated successfully");
                var claims = context.Principal?.Claims.Select(c => $"{c.Type}: {c.Value}");
                Console.WriteLine("Claims: " + string.Join(", ", claims ?? Array.Empty<string>()));
                return Task.CompletedTask;
            }
        };
        */
    });

builder.Services.AddAuthorization();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddOpenApiDocument(); // Add NSwag services

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseOpenApi();
    app.UseSwaggerUi();
}

app.UseHttpsRedirection();

var summaries = new[]
{
    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};

app.MapGet("/weather-forecast", (ClaimsPrincipal user, HttpContext context) => //, ILogger<Program> logger) =>
{
    /*
    logger.LogWarning("=== REQUEST RECEIVED AT /weather-forecast ===");
    logger.LogWarning($"user.Identity.IsAuthenticated: {user.Identity?.IsAuthenticated}");
    logger.LogWarning($"user.Identity.Name: {user.Identity?.Name}");
    logger.LogWarning($"Claims count: {user.Claims.Count()}");

    var authHeader = context.Request.Headers["Authorization"].ToString();
    logger.LogWarning($"Authorization header present: {!string.IsNullOrEmpty(authHeader)}");

    
    if (!string.IsNullOrEmpty(authHeader) && authHeader.StartsWith("Bearer "))
    {
        var token = authHeader.Substring("Bearer ".Length);
        logger.LogWarning($"Token (first 50 chars): {token.Substring(0, Math.Min(50, token.Length))}...");

        // Decode JWT to see audience
        try
        {
            var handler = new System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler();
            var jwtToken = handler.ReadJwtToken(token);
            logger.LogWarning($"Token Audience: {string.Join(", ", jwtToken.Audiences)}");
            logger.LogWarning($"Token Issuer: {jwtToken.Issuer}");
        }
        catch (Exception ex)
        {
            logger.LogError($"Failed to decode token: {ex.Message}");
        }
    }
    */

    var forecast = Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        (
            DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            Random.Shared.Next(-20, 55),
            summaries[Random.Shared.Next(summaries.Length)]
        ))
        .ToArray();
    return forecast;
}).RequireAuthorization();

app.Run();

internal record WeatherForecast(DateOnly Date, int TemperatureC, string? Summary)
{
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}
`

[guardrex]

Thanks @GC-brian-taylor ...

Have similar but not identical issue docs said to use "api://11112222-bbbb-3333-cccc-4444dddd5555" but I had to remove "api://"

That one is covered now because it instructs to use just the client ID.

Another issue in the doc is it said to use "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee" but I had to add a "/" at the end

That one I'll double-check when I get back (I'm OOF until Monday), and then I'll update both the sample apps and the article.

I'll leave the GH ping in my Inbox to avoid losing track of this.

UPDATES (4/20) ...

• The trailing slash is now on the existing PR for V2 token guidance. I hope to get that reviewed and merged soon.
• I opened an issue to add troubleshooting guidance on getting the token for failed requests. I'll get to it as soon as I can, probably next week. I'm going to try and resolve it now on that ☝️ PR.