Question 104708 in Azure Question posted in
The official documentation to get you started can be found here.

Difference between an application role and scope in Azure AD app registrations

I have created an API that is protected by OAuth using an app registration in Azure.
My app registration does not require assignment, but it exposes a number of roles that the underlying API verifies. To my understanding, this accomplishes almost the same thing as requiring approval.

So far I’ve only had user/group roles but now I’ve added an application role intended for integrators, and I want other application owners to be able to request permission to my API. I, as the API owner, would like to review these and either reject or consent to the request. E.g. I don’t want everyone to be able to access my API within the tenant without my knowledge, just like all users/groups don’t have access with me assigning them to a role.

The Role-based access control for application developers documentation makes it very clear who manages access:

…an application developer defines roles rather than authorizing individual users or groups. An administrator can then assign roles to different users and groups to control who has access to content and functionality.

However, if you create a role with allowed member types set to application, things are not quite as clear and it seems to behave more like a scope, where I give up any access management. Also from my limited understanding, a scope is used when the API needs to request data from the user (e.g. wanting to read their username), whereas a role is used for the application developer to control access to what they are developing.

This is what it looks like when I request access to my API from another app:
enter image description here

This same page mentions the following information:

The "Admin consent required" column shows the default value for an organization. However, user consent can be customized per permission, user, or app. This column may not reflect the value in your organization, or in organizations where this app will be used.

As well as:

Applications are authorized to call APIs when they are granted permissions by users/admins as part of the consent process

However, from my reading, it sounds like this never gives me, as the API owner, any insight into who has access to the API I own. I want to control application access the same way I’d assign a group or user to a role in the enterprise application.

Can this be achieved when it’s an application on the other end, not a user? If not, how would I allow applications to integrate in a controlled manner?

Tags:

2

Answers


  1. 0

    The App Registration > Permissions section has a great feature for reviewing and limiting the access provided for your app registration:
    enter link description here

    In addition you should always define the scope of your permissions and limit it to the least required for your app. eg. NEVER set scope at the subscription level! Always set it at the resource group or lower.

    Also note that Microsoft now provides Defender for APIs and you can use Sentinel to monitor a lot of the activities related to your app registration. Always always enable logging wherever possible and configure some method of alerting/reporting so you can better understand the activities for your app.

    Login or Signup to reply.
  2. 0

    I want to explain the feature Azure ad provided to protect web api here.

    As you know, we usually use a token in the request header to let the api check if the request had correct permission to visit the api. Such as if the request from an allowed user role, right? So to whole progress should be authentication and authorization. Users sign in first then try to generate an access token to visit an api. Azure AD has similar architecture.

    If you had a web application(e.g. web mvc app) you can integrate Azure AD into it then you can allow users use their [email protected] account to sign in. If you had a web api project, you can also integrate Azure ad and add [Authorize] attribute above the controller so that the incoming request should contain a correct Bearer token which we call it access token.

    For Azure AD, we usually have 2 options, verification scopes or app roles. That results from the different flows we used to generate the access token. For example, we use auth code flow to sign in users and generate access token containing scp claim which is granted delegated api permissions. And we use client credential flow to let an application to generate access token containg roles claim which representing it’s granted application api permissions. In short, when we set [Authorize] + [RequiredScope(scopeRequiredByApi)] in the controller, it allows requests from a user(user sign in the app and call api), when we set [Authorize(Roles = "roleRequiredByApi")], it allows requests from the application(no user signed in and the app call api by itself).

    Here scopeRequiredByApi and roleRequiredByApi is what you exposed and then added to App Registration > Permissions. Just like Integrator you marked in the screenshot, it can be recognized as roleRequiredByApi because its type is Application.

    And I’m afraid the roles is not what you want but to be honest what I said is what AAD can do for you… And I think the document I mentioned above about verification scopes or app roles will be a good sample for you.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search