In Day 7 we discussed paging results for Microsoft Graph requests. Today we’ll look at the current and future states of authenticating to Microsoft Graph, specifically obtaining access tokens.Any calls made to Microsoft Graph need to be properly authenticated by including an access token. In the case of Microsoft Graph an access token is a base 64 encoded JSON web token (JWT) which must be issued by Azure Active Directory (Azure AD).
There are 2 primary authentication flows against Azure Active Directory:
- On behalf of user
- Also called delegated or app + user
- Also called app-only
Depending on which authentication flow you build into your application the high-level steps will be as follows:
- Register application in Azure AD
- Configure / grant permissions
- Get access token
- Use access token to call Microsoft Graph
We’ll cover each of these steps in greater detail in later posts.
Knowing that we need to obtain an access token, let’s discuss the current and future states of authenticating to Microsoft Graph. Keep in mind there are a few elements that are currently in production supported preview.
Currently, authenticating against Microsoft Graph involves a few decisions as there are multiple portals to register an application, multiple client SDKs, and multiple Azure AD endpoints. Knowing your target audience is a key decision point as it influences which components you can or can’t use. MSAL and the Azure AD v2 endpoint are the go-forward direction (see Future state below) and as such we recommend you start there. ADAL and the v1 endpoints currently support a limited number of authentication scenarios that aren’t yet in MSAL / Azure AD v2 endpoint but those differences are expected to be addressed soon . Please see the article for Comparing the Azure AD v2.0 endpoint with the v1.0 endpoint link in the appendix for the most up-to-date information on deciding between v1 or v2.
The future state of authenticating to Microsoft Graph is targeting the following diagram. In this diagram notice that the Azure AD v2 endpoint can issue v1 or v2 tokens. Additionally, the Azure Portal is the sole location for registering applications. Overall the future state simplifies authenticating to Microsoft Graph by reducing the number of decision points and providing support for the broadest set of requirements.
We’ll cover the actual steps to obtain an access token over the next few posts. For the time being let’s inspect an access token such as the below sample (sensitive information obscured):
Note: An Azure AD access token is a Bearer token meaning any person or application that has possession of it can use it to make calls against Microsoft Graph with the consented permissions. As such you must ensure secure transmission and / or storage of them to prevent unintended use.
At first glance the format of these access tokens may appear unreadable, but you can decode them using various tools. The Azure AD team has provided the website http://jwt.ms as one example. The following is an example of the output from a sample access token.
Use the Claims tab after decoding an access token for additional information on each of the claims presented. This can be very helpful for troubleshooting an issue where an access token was generated with the incorrect scopes / roles, was issued for the wrong resource / audience, and more. Find additional information on the access token schema available in the Azure Active Directory Access Tokens resource.
Try It Out
Navigate to the documentation for Azure AD Access Tokens. Decode the v1 and v2 sample tokens using http://jwt.ms. Inspect the claims used for each
- V1 sample token
- V2 sample token
Join us tomorrow as we register Azure AD applications with the V2 endpoint in Day 9.