Grokking the AzureAD OAuth2 Implicit Grant Flow


  1. Authentication Scenarios for AzureAD

The OAuth2 Implicit Grant flow is designed for use by applications which cannot maintain the security of an application registration client secret, typically applications which run in a browser.

Unlike the Authorization Code grant flow, the implicit grant flow returns to the client an access token upon successful authentication when the user agent is returned back to the client application via the redirect_uri. In this post we’ll conduct an implicit grant transaction manually using the browser, then take the resulting access token and use Postman to call the GraphAPI to retrieve a users messages.

Setup Azure Application Registration

  1. Go to the old Azure management portal and navigate to your Active Directory instance
  2. Click on the Applications tab and click Add
  3. Select “Add an Application my Organisation is developing”
  4. Give your application a name and ensure “WEB APPLICATION AND/OR WEB API” is selected oauth1
  5. In the next dialog, enter a Sign-on Url (it doesn’t matter what it is for the purposes of this post)
  6. Enter a unique App ID URI, e.g.
  7. Click Complete

Configure your Application

  1. Navigate to your new application and click the Configure tab
  2. Make a copy of the Client Id value as you’ll need this later
  3. You don’t need a Key (Client Secret) for this OAuth flow
  4. Configure Permissions to Other Applications
  5. For Active Directory add the following Delegated Permissionsoauth3
  6. Add the Microsoft Graph application and select the following Delegated permissions
    1. Access users data anytime
    2. Sign users in
    3. Read user mail oauth3
  7. Add the URL of a publicly accessible website that you control to the Reply URL’s section, in my example I’m using a handy Azure website
  8. Click Save (Don’t forget this bit)

Create the Authentication URL

The authentication url is constructed as shown below, line breaks are included for clarity;<tenant id or tenant name>/oauth2/authorize?
client_id=<client id>
&redirect_uri=<url encoded reply url of the site which will receive the access token>

<tenantid or tenant name> – either use the tenant GUID or the tenant name,


<client id> – the client id of your Azure application that you saved earlier.

<response_type> – tells Azure what type of response you want, either an id_token, access token or both.

<redirect_uri> – a URL encoded reply URL, this is the URL Azure will redirect the response back to containing the requested response type included as a hash fragment. The URL you specify here must match at least 1 Reply URL in your Azure app registration by at least the URL scheme and host/origin.

<state> and <nonce> – are fraud prevention measures and are used as a mitigation against cross-site request forgery (CSRF) attacks, for more information, see Best Practices for OAuth 2.0 in Azure AD.

<resource> – this is the URL encoded URI of the resource you would like an access token for, if you are requesting an access token (see the response_type parameter), in this case I want to call the Graph API so thats the resource URI I’ve used.

So, the final URL might look something like this (ignore the line breaks);

Enter this URL into your browser, if you’re not already logged into Office365/Azure you’ll be presented with the login screen, enter your credentials and click Sign In.

You should now be navigated back to the URL you specified in the redirect_uri parameter with the inclusion of the request response type as a hash fragment.

My handy Azure website (that I set as the redirect_uri) decodes the hash fragment parameters as shown below;


You can see that the response includes an Access Token and an ID Token, indicates the token type (Bearer) and when the token expires. I can now take this access token and use it to call the Graph API.

Calling the Microsoft Graph API

For this bit we’ll use Postman to create the Graph API Rest URL and send that request, so, open Postman.


  1. Set the request type to GET
  2. Set the URL to$select=subject,sentDateTime,receivedDateTime,body&$orderby=receivedDateTime desc&$top=5

  3. Set the Accept header to application/json; odata.metadata=minimal
  4. Set the Authorization header to Bearer<space> followed by the access token
  5. Hit Send and bask in reflected glory…..


The OAuth2 Implicit grant flow is pretty straightforward as you’ve seen, and the most difficult part involves actually creating the correct URL’s. Because the Implicit grant flow is considered less secure than say, the Authorisation code grant flow, the resulting access token has a smaller lifespan, which I believe is 30 minutes, after which the access token will need to be renewed.

To use this type of authentication in your application, Microsoft provide the AdalJS library, which is a Javascript wrapper library implementing this flow and which takes care of a lot of the semantics and heavy lifting and presents a simple interface, which for the most part involves only a handful of method calls that you have to make in your application.

Behind the scenes, it also takes care of things like;

  1. Creating Authentication URL’s
  2. Parsing response hash fragments
  3. Caching of access tokens
  4. Monitoring the expiration of cached access token and silently renewing them
  5. etc

Published by

Phil Harding

SharePoint Consultant, Developer, Father, Husband and Climber.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.