InvalidOperationException: Either provide the 'ScopeKeySection' or the 'Scopes' to the 'AuthorizeForScopes'

[TiagoBrenck]

Please provide us with the following information:

AuthorizeForScopesAttribute is registered as a singleton, hence if you get it hit once by using the ScopeKeySection argument, the second time a MsalUiRequiredException is thrown you would have ScopeKeySection and Scopes populated (due to the singleton architecture) and the validation below will fail

if (!string.IsNullOrWhiteSpace(ScopeKeySection) && Scopes != null && Scopes.Length > 0)
{
      throw new InvalidOperationException($"Either provide the '{nameof(ScopeKeySection)}' or the '{nameof(Scopes)}' to the 'AuthorizeForScopes'.");
}

This issue is for a: (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

The issue was found for the following scenario:

Please add an 'x' for the scenario(s) where you found an issue

1. Web app that signs in users
   1. with a work and school account in your organization: 1-WebApp-OIDC/1-1-MyOrg
   2. with any work and school account: /1-WebApp-OIDC/1-2-AnyOrg
   3. with any work or school account or Microsoft personal account: 1-WebApp-OIDC/1-3-AnyOrgOrPersonal
   4. with users in National or sovereign clouds 1-WebApp-OIDC/1-4-Sovereign
   5. with B2C users 1-WebApp-OIDC/1-5-B2C
2. Web app that calls Microsoft Graph
   1. Calling graph with the Microsoft Graph SDK: 2-WebApp-graph-user/2-1-Call-MSGraph
   2. With specific token caches: 2-WebApp-graph-user/2-2-TokenCache
   3. Calling Microsoft Graph in national clouds: 2-WebApp-graph-user/2-4-Sovereign-Call-MSGraph
3. Web app calling several APIs 3-WebApp-multi-APIs
4. Web app calling your own Web API 4-WebApp-your-API
5. Web app restricting users
   1. by Roles: 5-WebApp-AuthZ/5-1-Roles
   2. by Groups: 5-WebApp-AuthZ/5-2-Groups
6. Deployment to Azure
7. Other (please describe)

Repro-ing the issue

Repro steps

1. Setup sample 4.1
2. Run it and open two browsers in incognito
3. Log in with different accounts in both browsers
4. Stop the application in Visual Studio, and run again
5. In one of the browsers, click on TodoList menu item
6. In the other one, click on TodoList and observe the exception being thrown.

Expected behavior

Microsoft.Identity.Web should be capable in handling MsalUiRequiredException multiple times, coming from different requests.

Actual behavior

An InvalidOperationException is thrown on the second time, even though the method is decorated with AuthorizeForScopesAttribute passing only the ScopeKeySection as parameter:

[AuthorizeForScopes(ScopeKeySection = "TodoList:TodoListScope")]
public async Task<ActionResult> Index()
{
      return View(await _todoListService.GetAsync());
}

[jennyf19]

cc: @jmprieur

[jmprieur]

@TiagoBrenck : why is it statically defined? it's an attribute instance? I don't get it. I looked at the doc for the exception filters, it does not say it's static?

[TiagoBrenck]

@jmprieur I don't know why it is statically defined. If you follow the steps mentioned above you will be able to reproduce the bug.

[jmprieur]

what happens is that the Scopes member is assigned (as an optimization) from the value of the resource, which means that next time we throw an error.
A fix would be to assigned the value of the resource into a different variable (which would not change Scopes).

This has actually good if we want to dynamically read the config file.

[TiagoBrenck]

Nice suggestion @jmprieur . I have opened a PR: #280

Honestly, I am still confused how come the Scopes kept assigned.

[jennyf19]

@TiagoBrenck it's because we're setting the Scopes value to whatever is in configuration.GetValue<string>(ScopeKeySection), then later checking if there is a value in both: if (!string.IsNullOrWhiteSpace(ScopeKeySection) && Scopes != null && Scopes.Length > 0), which there is, so then the InvalidException is thrown, even though the two scopes are the same.