How to change a display Name of a registered application from another application

Introduction:

This post will show you to change a displayName of a registered web application from another application using client credentials flow with Application Permission

Walk Through steps:

1) In Azure AD’s App Registration portal, create 2 new app registrations called TestAppA and TestAppB. We will use TestAppA to change the display Name of TestAppB. It is not important what permission you configure for TestAppB. For TestAppA make sure you configure Microsoft Graph’s Application.ReadWrite.OwnedBy permission (check the option for “Manage apps that this app creates or owns) under Application Permission and also click on the “Grant Permission” button to provide admin consent to TestAppA

Also note the Application ID for both TestAppA and TestAppB

2) For TestAppA create a new key and note its value:

3) Get the Object ID of TestAppA’s Service Principal from the Enterprise applications blade

4) Use Microsoft Graph Explorer tool to make the TestAppA’s Object ID obtained in step 3 the owner of TestAppB by issuing the following POST request:

POST https://graph.microsoft.com/applications/{id of App2}/owners/$ref
POST Body:
{

“@odata.id”:”https://graph.microsoft.com/v1.0/servicePrincipals/{SP ObjectId of App1}“

}

Note: Wait at least 20 minutes to perform the steps below:

5) For demo purposes I am using PostMan in this step to get an access token for TestAppA.

POST request to https://login.microsoftonline.com/<Directory ID>/oauth2/v2.0/token

POST body:

grant_type=client_credentials&scope=https://graph.microsoft.com/.default&client_id=<TestAppA App ID>&client_secret=xxx

6) Use PostMan to issue a PATCH request with an access token obtained above to change TestAppB’s displayName

PATCH https://graph.microsoft.com/beta/applications/<TestAppB App ID>
Body:
{

“displayName”: “new name”

}

Summary:

The steps above demonstrates the concept of how to change an application’s property such as displayName from another application. You can use the same technique to change an application’s other properties. The key here is that in order to change an application’s property, the calling app needs to have Application.ReadWrite.OwnedBy MS Graph permission and it needs to be an owner of the callee app. For demo purposes, this post uses PostMan to get an access token and issues an MS Graph call to change the property. In practice the calling application can use ADAL library to get an access token and make the same MS Graph call.

Using Postman to Call the Microsoft Graph API Using Client Credentials

Introduction

This blog post is to help users stand up an Azure Active Directory Application Registration, explain what permissions will be needed to added to the AAD Application Registration, how to make rest calls to get an access token, and then finally call the Microsoft Graph API to do whatever call you would like to do.

Please note, that not all permissions are going to be within Azure. i.e. If you are making a Microsoft Graph call to Outlook and would like access to a calendar using a delegated permission, and the user making the call doesn’t have access to said calendar, the call still will not work as the user does not have access to the calendar.

Also Please note that there are two different versions of the Graph API, the Azure Active Directory Graph API and the Microsoft Graph API.

In addition to that, note that the Microsoft Graph API has two endpoints right now, the beta endpoint and the V1 endpoint, do not confuse this with the v1 and v2 endpoints for Azure portal as the azure v1 and v2 endpoints are not related to the Microsoft Graph’s v1 and beta endpoints.

Setting Up the AAD Application

The first step to getting access to the Microsoft Graph REST API is to setup an AAD Application Registration.

First we are going to want to create the AAD Application registrations in the portal. For this we will need to configure the application to be able to work with Postman so that we can make the call to the Microsoft Graph API. First we go to the Azure Active Directory Blade, go to App Registrations, and then create a new application registration.

From there we are going to want to create a web app with any name. Here I have set the name as web app, and set the Sign-On URL as the callback for Postman: https://www.getpostman.com/oauth2/callback, it is unimportant what the callback url is, but for our case we are using that callback URL for consistency sake. Just make sure that the callback you put down for your AAD Application Registration is the same in your postman call. This is unimportant for the grant type client credentials but more important for other grant type flows.

You will have to click out of the sign-on URL to make it check whether or not if it’s correct.

After that we have created our web app, we will want to create a secret. Please keep track of the secret as you won’t be able to see the secret again. You will have to press save in order for the secret to generate.

With this information in hand, we will be able to move forward and connect to this AAD registration. But without the correct permissions we won’t be able to get an access token to make calls to the Microsoft Graph API.

Finding Which Permissions We Need for a Microsoft Graph Call

Assuming we would like to have granular control on what the AAD Application registration has access to and what it doesn’t have access to. We are going to want to make sure that the AAD Application registration only has the permissions it needs to make the MSFT Graph API calls that we are wanting to make.

There has been a separate blog post on finding the correct permissions for your graph API call listed below :

https://blogs.msdn.microsoft.com/aaddevsup/2018/05/21/finding-the-correct-permissions-for-a-microsoft-or-azure-active-directory-graph-call/

For this client credentials flow, we will want to set the required permission for Read all users’ full profiles under Application Permissions. If you check the delegated permission you won’t get the correct permissions because the client credentials flow only gets the application permissions. This permission is shown below.

Accessing the AAD App Registration and Calling the Microsoft Graph API

Now lets get a secret for our AAD Application registration by going to the keys blade and adding a secret. Please make sure to keep track of this key as you will not be able to retrieve it again once you leave the blade.

Be sure to press the save button in order to see the value after putting in the description for your key.

Now our AAD Application registration is ready to go and we can utilize postman to get an access token using the AAD Application registration to use the list users functionality in the Microsoft Graph API.

Please keep track of the client id as well which is the application id for your app registration. This is shown below.

We are going to want to get our token and authorize endpoints, we can find this next to the new application registration button in the App Registrations blade shown in the picture below.

Now we can go to our postman to try to get an Access token. Below is a screenshot of how the postman should be setup with the variables we got from the steps above.

We will use the token endpoint as the URL to post, we will then add the client id, client secret, resource, and grant type in the body of x-www-form-urlencoded fields.

The only item that isn’t gotten in the steps above is the resource which is different depending on what you’re trying to access. Here we are trying to access the Microsoft Graph which is https://graph.microsoft.com you will need to look through your respective documentation to find what the resource url is for the resource you’re trying to utilize if it’s not the Microsoft Graph.

After this we have now received an Access token back from the token endpoint for your Azure Active Directory tenant. With this access token we can create a new request with a single authorization header and the list user calls to the Microsoft Graph API.

We to have a header with the value as “Bearer <access token>” with the key “Authorization”.

We have now gotten the list of users from the tenant that the AAD Application Registration.

Conclusion

After going through the steps to create an AAD Application registration, finding what call we want to make, finding what permissions we need to make the call and then getting all the configurations we need to get an access token from the token endpoint. We were able to get an access token from the token endpoint and then make a call to the Microsoft Graph API with our access token to list the users in our tenant. I hope that you can utilize this flow to make the other calls to the Microsoft Graph API. If you have any issues feel free to open a support ticket and one of our support engineers will reach out to you as soon as possible, please be sure to have a fiddler trace of the error that you are experiencing.

Finding the Correct Permissions for a Microsoft or Azure Active Directory Graph Call

Introduction

This post is to help define how one can find out which permissions are needed for a specific Graph API call.

Assuming you want to have granular control over each AAD Application Registration, having the exact permissions required to do exactly what you need helps to secure your environment from users abusing permissions that you may have granted in excess.

Whenever someone wants to utilize the Microsoft or AAD Graph API, they have to grant the correct permissions for the AAD Application Registrations properly in order to be able to utilize the call.

Also for more information between the two Graph APIs please look here : https://blogs.msdn.microsoft.com/aadgraphteam/2016/07/08/microsoft-graph-or-azure-ad-graph/

Note: that just because you have been given the ability to make a call, doesn’t mean that the call will be authorized and go through properly. I.e. for o365 calendar issues, if you are logged in as user1 and retrieved a delegated access token and try to access the calendar of user2 and you don’t have access to user2s calendar as user1, you won’t be able to access the calendar. Just because you have granted permissions to access calendars, doesn’t mean that your user can access a calendar that he/she doesn’t have access to in the first place.

Finding Which Permissions We Need for a Microsoft Graph Call

Finding the permissions for the Microsoft Graph API is easier because there is a direct mapping for each Microsoft Graph API call described on each Microsoft Graph API call.

To determine which permissions we are going to want, you will have to check the permissions at the top of the reference guide for an operation for the Microsoft Graph API.

For example :

I would like to be able to list some users from Azure using the Microsoft Graph API using a client credentials grant type. In order to do this we can check the reference guide for the Microsoft Graph API here :https://developer.microsoft.com/en-us/graph/docs/concepts/v1-overview

On the side bar we can see the reference guide for the Microsoft Graph V1 endpoint, since we would like to list users, I look in the users sections and see if there is a list users.

It seems that there is a list users call, so I click on that. At the top of the list users API documentation, we can see the permissions that are needed :

Depending on how you plan on getting your access token you will either pick the application permission or the delegated permission, the differences between application and delegated are described here : https://docs.microsoft.com/en-us/azure/active-directory/application-dev-delegated-and-app-perms.

With client credentials we will need to utilize the application permissions, the delegated permissions can be used for the code grant type, or a flow that uses a user in addition to login.

For more information on permissions you can go to the permissions page for Graph API here : https://developer.microsoft.com/en-us/graph/docs/concepts/permissions_reference

In this blog post we will utilize the list users functionality, and we will want the permission to have user.read.all (the least privileged) so that we can list users from the AAD Application registration.

Now, in the AAD Application registration, it defaults to applications listed under “my apps” which means applications you are considered owner of. This is not going to be related to getting an access token to the Microsoft Graph API, so we are going to disregard not being the owner of the application. Please press the box that says view all applications to get access to your app shown in the picture below.

You can also change the box that says my apps to all apps to show all the applications in your tenant.

From here we will click on the application that you created, we will want to go to the required permissions blade described in the picture below :

After pressing the “Add” button, we will want to add the permission for the Microsoft Graph shown below.

Notice how the permissions have descriptions, and not the exact claim. Since we want to get the user.read.all permission we will want to determine which one of these permissions will give the claim user.read.all. We can find this in the permissions reference, for users we can find it here : https://developer.microsoft.com/en-us/graph/docs/concepts/permissions_reference#user-permissions

Notice this is under the delegated permissions, if we scroll down a bit more we will find the application permissions section.

We will want to find the corresponding display string in our permissions list “read all users’ full profiles” and check the button and press the done button.

After adding the user.read.all permission for the Graph API we will need to press the grant permissions button because this permission requires admin consent. You can see if it requires admin consent by seeing if it says yes under the admin consent column.

Below shows where the grant permission button is next to the Add button in the portal. This will need a tenant global admin to grant admin consent for it.

We have now gone through the process to make a Microsoft Graph Call and should be able to connect to the AAD Application Registration now and make the call to the list users functionality. Remember that whether you pick application permission or delegated permission will determine whether or not you get an access token with the correct scopes depending on your grant type flow.

Finding Which Permissions We Need for an AAD Graph API Call

Finding the exact permission you need for the AAD Graph API calls is a bit tricky. This is because there isn’t a direct mapping between permissions and AAD Graph API calls. By this I mean you won’t be able to see a call and be able to read exactly which permission it needs in order to access the call.

You will have to look through the permissions/scopes for the AAD Graph API and determine what the call you would like to use is trying to do and draw comparisons to the permissions described in the permissions page : https://msdn.microsoft.com/en-us/library/azure/ad/graph/howto/azure-ad-graph-api-permission-scopes

For example, let’s say we would like to get a user’s manager described as this AAD Graph API Call :

https://msdn.microsoft.com/en-us/library/azure/ad/graph/api/signed-in-user-operations#GetMyManagerObject

We will have to read the call, and see what exactly we are doing first of all. To get a manager object, as described in “Operations on Navigation Properties”:

Relationships between a user and other objects in the directory such as the user’s manager, direct group memberships, and direct reports are exposed through navigation properties. When you use the me alias, you can read and, in some cases, modify these relationships by targeting these navigation properties in your requests.

So we are trying to access the “Navigation Properties” of a user object. The manager endpoint retrieves the sign-in user’s manager object from the manager navigation property. This means that we are going to want to get the permission that allows us to read navigation properties of users. Now going back to the permission scopes page, we can look and try to determine which permissions we will need in order to read navigation properties. Luckily this scenario is listed under “Permission Scope Scenarios”

But imagining that it doesn’t fit under the permission scope scenarios, you can look at the permission scope details.

The permissions scope details defines all the permissions for windows azure active directory. Notice how user.read’s description says it cannot read navigation properties. Since the manager object is a navigation property, we are going to have to look at the user.read.all permission which is a superset of permissions of user.readbasic.all. The extra permissions it user.read.all has however as said in the description is that it is allowed to read navigation properties which is the manager object’s property.

Thus after giving an AAD Application registration the User.Read.All command we will be able to utilize the getmymanagerobject AAD Graph API call in order to get the Manager Object.

Essentially we will be going through the scenarios and then the permission scope details to determine the permissions we will need in order to call the AAD Graph API.

Conclusion

We have now gone through an example process of finding the permissions for both the Microsoft Graph API and the Azure Active Directory Graph API. There are some minute differences between the two Graph APIs, and require a different process to determine which permissions should be allowed in order to make a graph api call.

If you experience anymore issues please file a support ticket and one of our support engineers will reach out to help you in regards to this issue.

Receiving CORS Redirection Error when Signing into App Service using Azure AD

Introduction

This post is to help explain what is occurring when the CORS redirection error occurs when trying to navigate back to the login page after logging in. This doesn’t occur when the user is using a private browsing method/mode. The error that is typically received is error :

“Failed to load https://login.windows.net/{GUID} (index):{GUID}/oauth2/autho…{GUID}&state=redir%3D%252F.auth%252Fme%253Fv%253D1518029528427: Redirect from ‘https://login.windows.net/…{GUID}&oauth2/autho…{GUID}&state=redir%3D%252F.auth%252Fme%253Fv%253D1518029528427′ to ‘https://login.microsoftonline.com/{GUID}/oaut…{GUID}&state=redir%3D%252F.auth%252Fme%253Fv%253D158029528427′ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘{my-origin}’ is therefore not allowed access.”

Reason Why This is Occurring

In a typical scenario after a user authenticates to Azure AD to log into an application, Azure App Service sets a cookie called “AppServiceAuthSession” for that authenticated session with the client browser. The web application may use XMLHttpRequest / AJAX request for various functionality of the application and the request sent to Azure App Service would also contain the AppServiceAuthSession cookie. When this cookie is not present in the request, Azure App Service will redirect the request to Azure AD for login. This redirection causes the AJAX request to become a CORS request since the destination domain changes and Azure AD by default does not allow cross origin request.

Resolution

The Application needs to check for the existence of the AppServiceAuthSession cookie or if the session is still authenticated before sending the AJAX request. If the session is no longer authenticated, reload the entire browser window again and let EasyAuth handles the re-login process again.

Receiving AADSTS90094: The grant requires admin permission.

Introduction

This post is to help provide guidance when receiving the error : AADSTS90094: The grant requires admin permission.

Typically this error is received when trying to get access to an AAD application registration. Please note that there are two different Microsoft application portals:

https://portal.azure.com (v1 application portal) and the https://myapps.microsoft.com (v2 application portal).

For details on the different application models, please visit the following link:
What’s different about the v2.0 endpoint?

These different application models require different processes in order to resolve the AADSTS90094 error.

V1 Application Resolution

If you are using an AAD Application Registration under the URL portal.azure.com, then all that needs to be done is to click the “Grant Permissions” button.

NOTE: All application permissions require a tenant administrator to complete the consent process by clicking the “Grant Permissions” button.

To apply the permission scopes to the application, use the “Grant Permissions” button. If any of the permission scopes check in the Enable Access blade have Yes in the “REQUIRES ADMIN” column then a user with administrative permissions on the tenant will need to complete the consent process by clicking the “Grant Permissions” button.

This is also described in the article : https://docs.microsoft.com/en-us/azure/active-directory/application-dev-registration-config-grant-permissions-how-to

The link describes a second way to grant permissions.

V1 Application User Consent Disabled

Sometimes the tenant doesn’t allow users to consent for an application to access data on their behalf. This switch is shown in the picture below:

If the admin disabled users to be able to consent to allow third-party multi-tenant applications access their user profile data in the directory, the admins must consent to these applications before users may use them.

In this scenario, your app can require the users to provide the email of the admin of their tenant and send the admin-consent link to the admin.

Essentially in order to resolve the issue, you will have to get a global admin to generate the URL below. This is taken from the link : https://docs.microsoft.com/en-us/azure/active-directory/application-dev-registration-config-grant-permissions-how-to

You can construct a request to login.microsoftonline.com with your app configs and append on &prompt=admin_consent. After signing in with admin credentials, the app has been granted consent for all users.

So it would look like the below URL (replace with your app configs):

https://login.microsoftonline.com/<tenant-id>/oauth2/authorize?client_id=<client id>&response_type=code&redirect_uri=<Your-Redirect-URI-Https-Encoded>&nonce=1234&resource=<your-resource-Https-encoded>&prompt=admin_consent

V1 Enterprise Application/ V1 Multi-tenant Applications Requiring Admin Consent

In order to grant admin consent to a multi-tenant application you have in your tenant you won’t be able to press the grant permissions button since the Application Registration is in the creator’s tenant where the original AAD Application Registration in. If you’re receiving this error when trying to grant admin consent to a multi tenanted AAD Application you will need to get a global admin to grant admin consent on behalf of all the users in the tenant, following the same steps in the section before.

You will have to create this URL :

https://login.microsoftonline.com/<tenant-id>/oauth2/authorize?client_id=<client id>&response_type=code&redirect_uri=<Your-Redirect-URI-Https-Encoded>&nonce=1234&resource=<your-resource-Https-encoded>&prompt=admin_consent

Replacing the fields respectively with your tenant ID, Client ID, Redirect URI, and resource. Please contact the main multi-tenant AAD Application owner for information on the resource URI, it can be found in the original AAD Application Registration’s properties.

V2 Application Resolution

If you are using the https://myapps.microsoft.com portal, then you will need to utilize the adminconsent endpoint in order to properly grant admin consent for the v2 application model. This is described in the Microsoft Documentation at the following link:

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-scopes#using-the-admin-consent-endpoint

Conclusion

We have now described some scenarios where AADSTS90094 error could occur. If one of these solutions does not resolve your issue please file a support ticket and one of our support engineers will reach out to you to help resolve your issue. Please have the following information in your support request:

Fiddler trace if you can obtain one.
Correlation ID or Request ID along with its associated timestamp. With most AADSTS* type errors, the correlation ID and timestamp is provided in the error body text.

How to Get to the Keys/Secrets From Azure Active Directory

Introduction

This article has been written to help find where the keys/secrets are in the Azure portal depending on how you have set up your application. It will also provide some help in regards to extending/changing the Client Secret for an Enterprise Application in a Multi-Tenanted Scenario.

Custom AAD Registration Keys/Secrets

In order to access the keys for an AAD application registration, you can follow the steps highlighted below. You will essentially go to the AAD Registration Blade > App Registrations > (You’re App Name) > Settings > Keys. You will have to save the key with the name and expiration date before being able to copy and paste the key. In addition to that, you will not see the value in the Application Manifest as it’s now hidden and will be considered : Null.

Getting Keys/Secrets From an App Service Application Registration

This part of the article will define how to get the keys/secrets from the app service application. This will include creating the application from scratch. You will go to the app services blade : App Services > Add > Web App > Create.

After creating the web app, I’m going to go ahead and enable the web app to have authentication/authorization to create an AAD Application registration.

After enabling the Authentication/Authorization, I turn the management mode to express and then create a new AD Application and then press okay.

This will bring you back to the App Service Authentication/Authorization page. From there you will want to press the save button and then close out of the blade all the way back to the App Services blade in order to see the application registration in the AAD App registration.

After backing out of the App Service blades and going back to the blade with all App Services, you will be able to access the App Registration once you click on the Highlighted AAD button again.

When you access the AAD Authentication/Authorization setting again, you will see a new blade and you will be able to click on the button Manage Application now.

From here, this will open the AAD Application Registration and you can follow the same flow as the Custom AAD Application Keys/Secrets flow documented in the first section of this article.

Changing an Enterprise Application’s Secret

Please go to this blog post for more information on Enterprise Applications:

https://blogs.msdn.microsoft.com/aaddevsup/2018/05/23/how-to-create-and-add-keys-from-enterprise-applications/

Conclusion

Here in this article we have gone over three separate ways to find the permission/keys for your AAD registrations in both the Application Registration and the Enterprise Application. Please note that the Enterprise Application is actually a service principal for the Application Registration. More on this can be found here:https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-application-objects

The Service Principal described in the documentation is termed the Enterprise Application in the Azure Active Directory Portal. The managed application under the AAD App Registration also refers to the service principal. This link in the picture below highlighted will bring you to the Service Principal (Enterprise Application) of the Application Registration.

Query String is not allowed in redirect_uri for Azure AD

Problem:

See update at the end. This is no longer an issue.

Customer configures the following redirect URLs for his registered application in Azure AD

and issues the following request to authenticate to Azure AD:

GET https://login.microsoftonline.com/<tenant id>/oauth2/authorize?client_id=<app id>&redirect_uri=https%3a%2f%2flocalhost%3a44396%2fbac%2faad%3freqId%3dA123&response_mode=form_post&….

After logging in he is redirected to https://localhost:44396/bac/aad instead of https://localhost:44396/bac/aad?reqId=A123.

The redirected URL does not have anything after the query string.

Root Cause:

The behavior is by design. This is an Azure AD’s security feature to prevent Covert Redirect attack.

Resolution:

We recommend customer to make use of the ‘state’ parameter instead of using query string to preserve the state of the request.

Update 8/15/2019

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new

https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-breaking-changes#redirect-uris-can-now-contain-query-string-parameters

Azure AD now can accept reply URLs with query string. This can be done by modifying the manifest file in the App Registration portal like the following. This functionality is currently not available in the UI yet.

…

“publisherDomain”: “xxx.onmicrosoft.com”,
“replyUrlsWithType”: [
{
“url”: “https://localhost”,
“type”: “Web”
},
{
“url”: “https://www.contoso.com/otdsws/login?authhandler=Microsoft+OAuth”,
“type”: “Web”
}
],

“requiredResourceAccess”: [
{

Update 8/23/2019 – You now can enter reply URL with query string in the App Registration UI

V2 App Registration is missing an “Add Owner” button

Problem:

Customer registers an application in the app registration portal (https://app.dev.microsoft.com). He is not able share the application with other users since the “Add Owner” button is missing.

Root cause:

This problem can happen if the user registers the application in the app registration portal (V2 portal) under his personal MSA account. The behavior is documented in the following link:

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-limitations

Resolution:

Re-register the application under an Azure AD account (*.onmicrosoft.com account).

Implementing Service to Service Authorization and Getting the Access Token with Postman Utilizing Client Credential Grant Type

Introduction

This article is meant to show how one can set up a client application to obtain a service to service access token, to get access to a web API from a web App. This document will be following the grant type client credential flow to do this, and will utilize Postman to get the access token via client credentials. This tutorial will not set up the backend web API, and assumes that web API is validating the token, you can click this link on validating the JWT token here. Also in addition to that, the link included assumes that the Audience has the correct permissions. As the client credentials flow can get a different audience within your tenant, the end of this article will review what additional steps, to make sure that the access token has the correct permissions.

Creating the AAD Application Registrations in the Portal

First we are going to want to create the AAD Application registrations in the portal. For this we will implement the application to be able to work with Postman so that we can display getting the access token pretty easily. First we go to the Azure Active Directory Blade, go to App Registrations, and then create a new application registration.

From there we are going to want to create a web app with any name. Here I have set the name as web app and then we want to set the callback url to : https://www.getpostman.com/oauth2/callback and set the application type to web app/ API.

You will have to click out of the sign-on URL to make it check whether or not if it’s correct.

With this information in hand, we will be able to move forward and connect to this AAD registration. But without the correct permissions we won’t be able to connect to the web API registration with an access token from this web API.

So here I create the API registration, with the sign-on URL as the localhost. How you plan on setting up your application will change what the sign-on URL will be.

Modifying the Application Manifest to Add Your Own Permissions

Since we are utilizing Client Credentials, we will need to add the permission in the Web API as an Application Permission as the Client Credential doesn’t utilize the delegated permissions. In addition to that we will most likely want to define what sort of permissions the web app should have for the web API. In order to do this we will have to add these permissions directly into the web API’s application manifest. You can do this by going to the AAD Application registration, clicking on Manifest and then adding the field “approles” into it. This is shown below.

The approle I added here is below. By setting the allowedmembertypes to “Application” we are setting it as an application role.

“appRoles”: [
{
“allowedMemberTypes”: [
“Application”
],
“displayName”: “Test Application Permission”,
“id”: “3ea51f40-2ad7-4e79-aa18-12c45156dc6a”,
“isEnabled”: true,
“description”: “I am a Test Application Permission.”,
“value”: “Test.Application.Permission”
}
]

To learn more about these values you can go to the link here describing the application manifest :

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-application-manifest

To learn more about the App roles for an application please go here:

https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/app-roles

That being said, the one thing to note is that the allowedmembertypes isn’t described fully in the documentation above. By setting it to User, we set it as a delegated permission and have to ability to do RBAC access with the delegated permission. By setting it to an Application, we are able to set it as an application permission, letting anyone who can access the application to be able to access web API with the permissions granted to the web app.

You can learn more about the differences between delegated and application permissions here.

If you are interested in utilizing RBAC to control access in a service to service scenario you can follow this guide :

https://azure.microsoft.com/en-us/resources/samples/active-directory-dotnet-webapp-roleclaims/

In addition to that, the ID is created by utilizing the method below in PowerShell.

[System.Guid]::NewGuid()

Adding the Permission into the Web App

After adding the application permission in the application manifest, we are able to add the required permission to the web app in order to get an access token with the correct claims saying that this web app has application access to the web api.

Now we have the Application permission and we will be able to get it in the claims when we authenticate with the web app. Make sure to grant permissions, otherwise you won’t see the role in the access token as the application technically hasn’t been given permission yet as it requires a global admin to give the application access to the permission. Notice how it says yes under require admin in the last picture.

Getting the Access Token with Postman

After granting permissions for the application, we are now able to authenticate with the application and get the correct claims and audience in the access token. We will utilize client credentials to get an access token from Web App’s application ID with the secret and then with the resource set as the app ID URI for the web API, we will get the audience as the app id uri, and the roles for whatever permissions were granted to the web app.

From here, you can access the web api, assuming that you have set it up to authorize based on the audience, role, iss, and signature is correct (i.e. the access token hasn’t been tampered with and it is issued from the AAD tenant with the AAD Application registration in it). For more information on validating a JWT token you can find that here.

Conclusion

We have now gone through all the steps to set up the AAD application registration, modify the application manifest in the web API to create the permissions, add permissions in the web app aad application registration, grant permissions, and get the Access token using Postman to see if all the claims in the JWT token are correct. After all of this your web api will need to still manually validate that the jwt token hasn’t been tampered with and that all the claims are correct. After doing all these steps you should have now setup a service to service authorization using client credentials.

Introduction:

Walk Through steps:

Summary:

Introduction

Setting Up the AAD Application

Finding Which Permissions We Need for a Microsoft Graph Call

Accessing the AAD App Registration and Calling the Microsoft Graph API

Conclusion

Introduction

Finding Which Permissions We Need for a Microsoft Graph Call

Finding Which Permissions We Need for an AAD Graph API Call

Conclusion

Introduction

Reason Why This is Occurring

Resolution

Introduction

V1 Application Resolution

NOTE: All application permissions require a tenant administrator to complete the consent process by clicking the “Grant Permissions” button.

V1 Application User Consent Disabled

V1 Enterprise Application/ V1 Multi-tenant Applications Requiring Admin Consent

V2 Application Resolution

Conclusion

Introduction

Giving Consent for All Users for Microsoft Graph Explorer

Resolution

Introduction

Custom AAD Registration Keys/Secrets

Getting Keys/Secrets From an App Service Application Registration

Changing an Enterprise Application’s Secret

Conclusion

Problem:

Root Cause:

Resolution:

Problem:

Root cause:

Resolution:

Introduction

Creating the AAD Application Registrations in the Portal

Modifying the Application Manifest to Add Your Own Permissions

Adding the Permission into the Web App

Getting the Access Token with Postman

Conclusion