search

AzureAD / microsoft-identity-web

Helps creating protected web apps and web APIs with Microsoft identity platform and Azure AD B2C
MIT License
684 stars 217 forks source link

[Bug] TokenAcquisition for User Impersonation retrieves different token in Web App then locally #1501

Closed vincentscheel closed 3 years ago

vincentscheel commented 3 years ago

Which version of Microsoft Identity Web are you using? Microsoft Identity Web 1.18.0

Where is the issue?

Is this a new or an existing app? This is a new app.

Repro: In this web app I am trying to use UserImpersonation to call Azure Storage Account operations. I have followed this guide: https://docs.microsoft.com/en-us/azure/storage/common/storage-auth-aad-app?tabs=dotnet

As long as I run locally, this will work. I get a connection to the Storage Account as the user that signed in to the Web app and can do the expected operations. However, when I deploy the same code to an Azure Web app, things get interesting. First I started to see an expired token error, when opening the page in a browser window I have been using for a while (and had logged in on many times). After this, I opened the web app in an anomynous browser. It prompts me to login and after doing so, it will give me a 401 with somewhere in the details "AuthenticationErrorDetail: Audience validation failed. Audience did not match".

This made me expect that I either reuse a token or get an incorrect token from MSAL when running in an Azure Web app. To test this theory I added the following code to the top of the first Controller method called to retrieve a token manually and print it in AI:

var token = await _tokenAcquisition.GetAccessTokenForUserAsync(new[] { "https://storage.azure.com/user_impersonation" });
_logger.LogError("Received token: " + token);

When running this locally, I get a token with the audience and scope I expect and that works (removed some stuff from the token to shorten it):

{
  "aud": "https://storage.azure.com",
  "exp": 1635347238,
  "appid": "SomeGUID",
  "appidacr": "1",
  "family_name": "LastName",
  "given_name": "FirstName",
  "groups": [
    "<SNIP>"
  ],
  "scp": "user_impersonation",
  "ver": "1.0"
}

However, in the Azure Web App I get the following token (again removed a lot):

{
  "aud": "https://graph.windows.net",
  "iss": "https://sts.windows.net/3a15904d-3fd9-4256-a753-beb05cdf0c6d/",
  "exp": 1635336739,
  "scp": "email openid profile User.Read",
}

I cannot figure out why I get a completely different type of token when the code is running on an Azure Web App or when it is running locally.

Possible solution ...

Additional context / logs / screenshots All app settings are the same locally as well as on the Azure Web App.

This is a part of my startup:

public void ConfigureServices(IServiceCollection services)
{
      var initialScopes = new[]
            {
                // A full string array of the scopes you want the user to consent to...
                "https://storage.azure.com/user_impersonation"
            };

       services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
                // Add login screen
              .AddMicrosoftIdentityWebApp(Configuration.GetSection("AzureAd"))
              // Enable user impersonation
               .EnableTokenAcquisitionToCallDownstreamApi(initialScopes)
                            .AddInMemoryTokenCaches();
jmprieur commented 3 years ago

@vincentscheel did you enable app service authentication? I suspect you do, and it's configured to get a token for Microsoft.Graph, not for storage. If you do, I would recommend, for your scenario, or disable app service authentication (you don't need it as your app already processes everything for you)

vincentscheel commented 3 years ago

Hi @jmprieur . Thank you for your response. We did have app service authentication enabled and it was indeed configured for Microsoft.Graph. After changing that to https://storage.azure.com I get the correct token and it works. Thank you for your pointer - I did not find this anywhere. Hope this helps someone in the future.

Have a good one!

vincentscheel commented 3 years ago

Hi @jmprieur. Some time has passed and I am stil a little stuck on this. Getting a token now works, but after about one hour, the token is expired and I get an error from the StorageAccount API (Lifetime validation failed). Should the MSAL framework not take care of refreshing the token in the background?

I use the code from the sample linked in the original question (same startup as above).

[AuthorizeForScopes(Scopes = new string[] { "https://storage.azure.com/user_impersonation" })]
public async Task<IActionResult> Index()
{ 
       var dataModel = await _someProvider.GetSomething(new TokenAcquisitionTokenCredential(_tokenAcquisition), someExtraInput);

Futher down in the provider I provide the created TokenAcquisitionTokenCredential as input when creating a BlobContainerClient. I have been searching all over, but I have not been able to find what I do wrong. I also tried to switch to SessionCache instead of MemoryCache, but to no avail. Any insight you could provide will be highly appreciated!

jmprieur commented 3 years ago

When you are using app service authentication, this is that service that should refresh the token. If you disable app service authentication, then MSAL sill indeed to the refresh for you

Do you need app service authentication (and not just use the configuration in the appsettings.json)? Given your scenario is a bit advanced, you might want to do pure Microsoft.Identity.Web?

vincentscheel commented 3 years ago

Hi @jmprieur Thank you for your pointer. This was in fact the reason for the token not refreshing. I did not figure those would impede on each other like this. You saved my day!