Microsoft's OAuth2 implementation: Registering an app
In my last post, I explained the different API endpoints available for authentication using Microsoft’s OAuth2. Additionally, I shared the different types of applications and their authentication flows.
In Part 2, I will discuss how to create and register a new application with a deeper understanding of the permissions needed when interacting with the Microsoft Graph API.
Registration
Before you can use OAuth 2.0 or OpenID Connect authentication protocols, you first must register an application within your Azure Active Directory (AAD). Depending on your scope, you will need to create either traditional App registrations or App registrations (Preview). They are both similar, but the “Preview” version is for v2.0 applications, and the traditional is used for v1.0 applications. Personally, I recommend to always try and use the v2.0 endpoint, but you can view the difference between v1.0 and v2.0 here.
Authorization/Sign-In
Depending on you application type and the endpoint version you are using, the authorization/sign-in may be slightly different. Either way, after you register your application you will communicate with two different endpoints:
- V1.0 Endpoint
- V2.0 Endpoint
Example
Now that we understand the basic scenarios, let’s get into a real-life example. For this example, I will create an application and use the “Auth Code Grant” flow to interact with the Microsoft Graph API.
By visiting https://docs.microsoft.com/en-us/graph/auth-register-app-v2, you can register a basic Web application to access Microsoft Graph API. The first thing you will need to do is click on the “Add an app” button and enter a name for your new App.
Once you have entered your app’s name, you need to generate a new password by selecting the Generate New Password button under the Application Secrets section. After you generate a new password, this will only be displayed once. Make sure to keep this in a secure location. Go ahead and copy your password (Client Secret) now.
Under the “Platforms” section a new sub-section titled “Web” is displayed and contains two separate fields: Redirect URLs and Logout URL.
In the Redirect URLs field, enter where you want your authorization code to be redirected to. For this example, I am going to enter https://localhost. We do not have to worry about the Logout URL—this is out of scope for this example.
In the Owners section, you may have to add additional owners, but by default, this should be your Azure login.
Since we are using the “Auth Code Grant” OAuth 2.0 flow, you need to add any Delegated Permissions you would like your application to have now—of course we can modify this later.
Go ahead and click the “Add” button next to the Delegated Permissions section and select the following permissions:
- Mail.Read
- offline_access
- OpenID
- People.Read
- Profile
Go ahead and scroll down and select Save.
There are a few Microsoft Graph permissions listed here that stand out:
- offline_access
- OpenID
- Profile
These permissions allow you to specify additional artifacts returned from AAD authentication. Depending if your organization has Azure AD v1.0 or v2.0, you can use these permissions differently.
If your organization has Azure AD v1.0 then you can only authenticate to Azure AD using the OpenId Connection protocol. If you are using Azure AD v2.0 then you can use either OpenID Connection or OAuth2 protocols.
By providing the scope parameter in your authorization request (either AAD v1 or v2), you then need to specify the permission of OpenID for authenticating to Azure AD v1.0. If you are using Azure AD v2.0, then you can specify the OpenID permission when using OpenID Connect or use the offline_access permission when authentication using OAuth2. See the table below breaking all of this down.
URL Parameter | Azure AD v1.0 Permissions | Azure AD v2.0 (OpenId) | Azure AD v2.0 (OAuth2) |
scope | openid email profile User.Read | openid profile | offline_access profile |
After you have saved your changes, please write down your Application Id, Redirect URLs, and Delegated Permissions you selected. We will need these in the third and final part of this series: Using Microsoft Graph API.
*** This is a Security Bloggers Network syndicated blog from Swimlane (en-US) authored by Josh Rickard. Read the original post at: https://swimlane.com/blog/microsoft-oauth2-implementation-2/
