Options for obtaining an access token with Azure application to application authentication


  • Client app runs code to get an access token and calls the server app for data (say Orders).
  • The server app receives requests only from apps (not users) and expects certain claims to be present in the request.
  • The server app is secured using an app registration.
  • Based on the request received, the serve app does some computation and returns the data (Orders) to the client app.
  • If applicable, the client app then returns that data to end users.

Server app registration

An app registration is associated with the server function app. This app registration is server’s identity and is used to secure the server function app.

Secure the server function app

Application role

The server app registration is setup with an application role let’s say “Orders.Read” — which is a custom role. (This role is exposed as an application permission that can be added in other app registrations.)

Create an app role for the server app reg

Client function app

The client function app is a daemon app which uses it’s own identity (client app registration) to get data from the server function app. (The client function app can also be a non-daemon app but will still use it’s own identity (not users identity) to get data from server).

Orders.Read app permissions of the client app reg


All the code explained below can be found in this GitHub repository. Please note that the code is to show the concepts only and is not PROD ready.

Generating access token

Microsoft provide us with various authentication libraries which do all the hard work of computing the access token and checking it’s expiry. So, all we need to do is install one of those libraries in our project and use the methods that are provided by these libraries and get an access token. Let’s take a look at those libraries and the methods they provide:

1. ADAL (not recommended / deprecated)

Note: Using ADAL is deprecated hence not recommended. So use MSAL instead.


In MSAL.NET, apps are represented either as public client or confidential client applications. In our case the client app registration will be represented as confidential client application. So, we create a variable of type IConfidentialClientApplication using the ConfidentialClientApplicationBuilder class provided by MSAL. We need to provide the client app registration’s ID, it’s secret (or certificate in case of PROD) and the tenant ID.

Managed identities

Instead of using the client app registration to represent the client function app, we can create an identity in a different way for that function app by using managed identity. This will help us move away from maintaining client secret or certificate.

Permissions assigned to the managed identity

3. App Authentication client library for .NET

Note: For new applications Microsoft recommend using Azure.Identity instead of this library.

4. Azure.Identity library

Microsoft have mentioned in this article that “Azure.Identity can be considered as the spiritual successor of the App Authentication client library for .NET”. Using Azure.Identity library we create an instance of ManagedIdentityCredential class. This will automatically use the credentials of the managed identity configured for the client function app. We then call the GetTokenAsync method with the scopes as “ServerAppRegId/.default” to get an access token. The access token will have the server app registration’s ID in the aud claim and will have the Orders.Read entry in the roles claim.

Local development auth

During development if we want to test the above functionality (3 and 4) then, we have cannot use Managed Identity for authentication locally. Hence we have to use different methods of authentication.

Further enhancements

The code in the server function app at the moment checks only if the token has the correct roles claim. The code can be enhanced further to perform more checks based on the security requirement. Those checks might be verifying if the aud claim in the request is the intended one or not etc.


We have seen 4 different ways of getting an access token for a daemon app (Client) to call an API (Server)using the different libraries provided by Microsoft. Thanks to Microsoft, all the hard work of computing the access token is done by the libraries. We have seen how easy it is to use the methods provided by those libraries.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store



Microsoft MVP. M365 Developer Architect at Content+Cloud.