2

I have a web api to access "resources". These are not user specific resources.

There is a "reader" app role. User1 is added to "reader" role App1 has been granted permission to the "reader" role

[HttpGet]
[Authorize(Roles = "Reader")]
[RequiredScope("Asset.Read")]
public async Task<IActionResult> GetResource(Guid resourceId)

When user1 accesses the route, (with a token with the scope) it works.

When app1 tries to access the route it gets a 403 forbidden, even though it had ".default" which I thought would give it access to all scopes?

Question 1: Why can't app1 access the route?

Question 2: Why do I even need a scope? It seems like there is a lot of conflicting documentation on why to setup scopes.

Jason Hernandez
  • 2,907
  • 1
  • 19
  • 30
  • Related: [What is the difference between roles and scopes in Azure's role-based access control (RBAC)?](https://stackoverflow.com/questions/75850554/what-is-the-difference-between-roles-and-scopes-in-azures-role-based-access-con) – toraritte Mar 26 '23 at 21:07

1 Answers1

1

Question 1: Why can't app1 access the route?

In addition to what RahulKumarShaw-MT has answered, this likely is because for the OauthV2 Client Credentials flow for AzureAD, the JWT token issued with the /.default scope in the request does not bear an scp parameter for delegated permissions. This is likely what the "Asset.Read" scope is. For your scenario, you'll need to verify the scope parameter exists in the JWT in the case of clients that access data on behalf of the user e.g. Single Page Apps that do not use the Client Credentials flow, but skip the scope verification for Daemon Apps or confidential clients that use the Client Credentials Flow. This question highlights a similar issue to the one you're having.

Question 2: Why do I even need a scope? It seems like there is a lot of conflicting documentation on why to setup scopes.

You only need the custom-defined scope if your App is performing actions on behalf of the "signed in" user. Such as reading user data. If however, the App is not doing this and is instead a Daemon App or service in a non-public environment that can hold a client secret, then you should be able to assign an App Role and use the client credentials flow without verifying the app scope. App roles assigned to Daemon Apps will require admin consent.

Alfred Waligo
  • 2,809
  • 3
  • 18
  • 26
  • I'm not sure you, nor Rahul have answered the question of why we need both scope and roles. Feels like scopes and roles are the same thing with a different name just because they're used in different occasions – Michele Bortot Jul 15 '22 at 15:54
  • @MicheleBortot, One difference is that you can assume a role, but you cannot assume a scope. Scopes are designed for a third-party application and usually restrict the data the application can read/access on behalf of the user. e.g. the open id "email" scope allows the 3rd party application to read the user's email. Roles are different because they can be assumed by both applications and users. A user who assumes the role of "administrator" could technically have access to your user email in your org if they are not accessing the data through a third-party app. – Alfred Waligo Jul 15 '22 at 16:26
  • We, therefore, need scopes when we build applications that need to access information related to the current user (e.g. a signed-in user/entity). We need roles/application roles to ensure that the application/user assuming the role is authorized to do the actions defined by the role and not just pertaining to the current user. – Alfred Waligo Jul 15 '22 at 16:31