Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Getting Access Token for Microsoft Graph Using OAuth REST API, Part 2

DZone's Guide to

Getting Access Token for Microsoft Graph Using OAuth REST API, Part 2

We continue our investigation of REST API security by checking out the two types of flows developers will need to implement user permissions in their app.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

Welcome back! If you missed Part 1, check it out here.

Getting the Access Token

After we registered our OAuth App, got its Client ID and Secret, and configured its permissions, we can finally use AAD Services in order to get the Access Token.

In OAuth, there are several different ways to achieve access tokens, each suited for different a scenario. Those ways are called "grant flows," and, according to the desired flow, a different message needs to be sent. Let's review our different flows.

Flow 1: Get an Access Token From Client Credentials (Client Credentials Grant)

The most basic option is to use our Client ID and Secret in order to get an access token. For this, we need to send a POST message to our Azure Active Directory Authentication endpoint (which we talked about before) with following body parameters:

POST https://login.microsoftonline.com/<AAD_name>/oauth2/token
  • grant_type: The flow we want to use, client_credentials in this case.
  • client_id: The Client ID (Application ID) of the application we created in the previous step.
  • client_secret: The Client Secret we created in the previous step.
  • resource: The name of the resource we would like to get access, https://graph.microsoft.com in this case.

We will receive a response with a JSON object containing the following properties:

  • token_type: The value Bearer
  • expires_on: The token expire timestamp in Unix epoch time.
  • access_token: The access token we needed to access the Graph API

This option is called Client Credentials Grant Flow and is suitable for machine-to-machine authentication where a specific user's permission to access data is not required.

To learn more about this flow, see: Service to service calls using client credentials (shared secret or certificate)

Flow 2 - Get Access Token From Client and User Credentials (Resource Owner Credentials Grant)

The first option, while it is the simplest of all (since it only requires the Application ID and Secret), doesn't always work. There are several Graph Methods for which just using the client credentials is not enough - they require user authorization as well. For example, in order to retrieve Group Events, we can see permission ApplicationNot supported, meaning getting access to that resource with just Client Credentials will not work. However, the first line is, Delegated (work or school account): Group.Read.All meaning, if we can get a "delegated permission" we can make this work.

So what does "delegated permission" mean, you ask? Well in simple terms, we need to show the API that not only have we come with an approved Client, we also have to carry a valid User authorization as well. Meaning that our access token needs to contain both a valid Client and User claims.

So how can we do that? There are a couple of ways to achieve that, in this option, we will look at the simplest way - the Resource Owner Credentials Grant.

For this flow, we need to send the following POST message:

POST https://login.microsoftonline.com/{{AAD_name}}/oauth2/token
  • grant_type: The grant flow we want to use, password in this case.
  • client_id: The Client ID (Application ID) of the application we created in the previous step.
  • client_secret: The Client Secret we created in the previous step.
  • resource: The name of the resource to which we would like to get access, https://graph.microsoft.com in this case.
  • username: Full username of the user, including the domain, for example, john@contoso.onmicrosoft.com
  • password: User's plain-text password.

We will receive a response with a JSON object containing the following properties:

  • token_type: The value Bearer
  • expires_on: The token expire timestamp in Unix epoch time.
  • access_token: The access token we needed to access the Graph API.
  • refresh_token: A refresh token that can be used to acquire a new access token when the original expires.

To learn more about this flow, see: Resource Owner Password Credentials Grant in Azure AD OAuth.

Besides the access token, we received two additional tokens - Refresh Token and ID Token. They were are not necessary for this flow, but they can be used in other grant flows and this is an example of how to get them. We automatically get the Refresh Token in this flow, and we can get an ID Token by adding to the request scope parameter with the value openid, as seen in the above Postman screenshot.

That's all for Part 2, tune in tomorrow for the final post of this series where cover the last two flow types you need!

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
security ,oauth ,api security

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}