What is the correct use of scopes and app roles in an Azure AD web api with user and daemon clients?

user_34863 0
Viewed 356

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.

scopes azure-active-directory asp.net-core-webapi
1 Answers

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.

user_47241420
Related