4
votes

I am using Azure AD OAuth2 authorization, to secure my Web API. Now i need to support two OAuth2 scenarios(flows) -

  1. Web application accessing the Web API, and the API based on the user's role will serve a resource. This is the achieved using authorize oauth flow, and access control is done using Authorize[Role="Read"] attributes

  2. A daemon(console) application accessing the same Web API. Though i am able to get a token by using the client credentials oauth flow, but i am not able to figure how to manage access to the daemon process

Once the token is issues the console can literally access any of the API methods.

Scope - when grant_type is "client_credentials" scope is not a parameter to /token endpoint Role - Cant use it as this is associated with user

Can somebody please suggest, how we can do access control in client credentials flow ? And how i can cater both requirement 1 and 2 at the same time

2

2 Answers

5
votes

You can define "roles" for both the users and the applications in your API's manifest in Azure AD.

Application roles are actually application permissions if you are wondering.

So you can have something like this in your API manifest (other properties removed for clarity):

{
  "appRoles": [
    {
      "allowedMemberTypes": [
        "Application"
      ],
      "displayName": "Read all things",
      "id": "32028ccd-3212-4f39-3212-beabd6787d81",
      "isEnabled": true,
      "description": "Allow the application to read all things as itself.",
      "value": "Things.Read.All"
    },
    {
      "allowedMemberTypes": [
        "User"
      ],
      "displayName": "Read things",
      "id": "ef8d02ff-eee1-6745-9387-96587c358783",
      "isEnabled": true,
      "description": "Allow the user to read things.",
      "value": "Things.Read"
    }
  ]
}

So we are defining a role that allows only applications as its members. It's an application permission. The other is a role that can be given to users and groups.

You can then give users the Read things role, and the daemon console app the Read all things application permission. And you achieve both scenarios :)

You add the role to users/groups by going to Enterprise applications->Your API->Users and groups->Add user. Select the users/groups you want and then select a role for them (if you have only one it will be pre-selected).

After adding the role, the user will show up in the list

You add the application permission by finding the other application's App Registration->Required permissions->Add->Find your API->Select->Check the application permission you defined earlier from the list. Then you can press the Grant Permissions button to grant the app role.

Permissions required by the Web App on the API

You then get the value in the roles claim for either scenario.

So the roles claim will look like this in the first scenario:

"roles": [
    "Things.Read"
  ],

and like this in the second scenario:

"roles": [
    "Things.Read.All"
  ],
0
votes

You can get application role as you mentioned with token you get at Client side. But at server side (protected API side), there is no way to see Roles claims to authorize.

With User/Roles, you can create a mapping between Users and roles defined in Manifest file. So UI and API will know user roles to authorize.

With App/Roles, there is no way on Azure portal to create a mapping clientId/clientSecret to AppRole defined in Manifest.