Skip to content

OAUTH 2.0 with Microsoft

What is OAuth?

OAuth is an open-standard authorization framework that provides applications the ability for “secure designated access.” For example, you can tell Facebook that it’s OK for another website like to access your profile or even post updates to your timeline without having to give your Facebook password. This minimizes risk in a major way: In the event suffers a breach, your Facebook password remains safe.

OAuth doesn’t share password data, but instead uses authorization tokens to prove an identity between consumers and service providers. OAuth is an authentication protocol that allows you to approve one application interacting with another one your behalf without giving away your password.

This blogpost is primarily about OAuth 2.0 for Microsoft – if you have set up your app in Azure, you are ready to go.

If you are not familiar with API’s and access tokens, I suggest that you read this blogpost by my colleague:

If you are looking for something about OAuth 2.0 for Google, look here:

But – for now we will be talking about OAuth 2.0 for Microsoft. The official Microsoft documentation on OAuth 2.0 can be found here:

It can be a tough read, and I hope I can help you with this post.

I will assume that you have set up your app in Azure – which is where you will find all the information needed for the following steps.

To give an understanding, I will go through the process of setting up your authentication process the old way – but if you just want to get going, scroll down and find the easy solution.

We use Postman to develop API-calls. You can get it here:

OAuth 2.0 the old school way

Step 1

Using the following link, fill out your relevant information in the link: The information can be found on your Azure page.

This will probably return a page that cannot be reached – but don’t worry! Look at the URL address line – it should now be something like this:


What you need from this is code after ?code= and before &session_state= (it will probably be much longer!)

Step 2

Open Postman. Create a request with the following fields filled out:

This call will return an access token, a refresh token and an id-token. We only need the refresh token.

Step 3

Using the refresh token from step 2, change “code” to “refresh_token” and insert the new refresh token. Change the grant_type to refresh_token.

This call will return an access token and a new refresh token. The access token can be used to make standard API-calls to the API, acting as Bearer authorization.

The refresh token can be used to obtain a new access token, since it only has a lifetime of 1 hour. It is recommended to use the new refresh token for the next call every time, to avoid the refresh token expiring – which it will do in 90 days, or if it has not been used in a while.

OAuth 2.0 the easy way with Postman

In Postman, open a new tab. Select the “Authorization” under-tab. In Type, select OAuth 2.0 and click “Get New Access Token”.

The following window will pop-up. Fill it in with your information and click “Request Token”.

Auth URL should be like this:

The scope can be found in Azure under the APP – it could be user_impersonation

Press the button and boom! You have your access token and new refresh token.

OAuth 2.0 in your workflows

This process should of course be implemented in your workflows. After the first refresh-token is retrieved through Postman (the easy way), it is simple to implement a solution in your workflows – no need to worry about OAuth 2.0 anymore!

I suggest you create a macro that calls the API for a new access token that you use every time you want to make a call to the API. In the macro, store your credentials in a CSV-file. When you call for a new access token, you also retrieve a new refresh token. This should be written down to your CSV-file, ensuring that you always have a fresh refresh token. Remember a Block-Until-Done tool so you write to your CSV-file after you have read from it.