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
- Go to the old Azure management portal and navigate to your Active Directory instance
- Click on the Applications tab and click Add
- Select “Add an Application my Organisation is developing”
- Give your application a name and ensure “WEB APPLICATION AND/OR WEB API” is selected
- In the next dialog, enter a Sign-on Url (it doesn’t matter what it is for the purposes of this post)
- Enter a unique App ID URI, e.g. https://PlatinumdogsConsulting.onmicrosoft.com/MyCoolApplication
- Click Complete
Configure your Application
- Navigate to your new application and click the Configure tab
- Make a copy of the Client Id value as you’ll need this later
- You don’t need a Key (Client Secret) for this OAuth flow
- Configure Permissions to Other Applications
- For Active Directory add the following Delegated Permissions
- Add the Microsoft Graph application and select the following Delegated permissions
- Access users data anytime
- Sign users in
- Read user mail
- 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
- 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;
https://login.microsoftonline.com/<tenant id or tenant name>/oauth2/authorize?
&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.
- Set the request type to GET
- Set the URL to
- Set the Accept header to application/json; odata.metadata=minimal
- Set the Authorization header to Bearer<space> followed by the access token
- 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.
Behind the scenes, it also takes care of things like;
- Creating Authentication URL’s
- Parsing response hash fragments
- Caching of access tokens
- Monitoring the expiration of cached access token and silently renewing them