Microsoft’s OAuth2 endpoints and application types

 

As an information security or IT professional, understanding the concepts around Microsoft OAuth 2.0 or OpenID Connect authentication can be daunting. There are thousands of pages of documentation, and if you want to interact with a Microsoft Cloud service—like Microsoft Graph—it can be a minefield of information.

In this three-part series, I am going to share with you my insights on Microsoft’s OAuth2 Implementation in hopes that it will help your organization understand and use OAuth2 when using Microsoft cloud-based services. This series is broken out into the following parts:

• Part 1: Endpoints and Application Types
• Part 2: Registering an Application
• Part 3: Using Microsoft Graph API

Every day, you use OAuth2 or OpenID—whether you know it or not. If you use Microsoft, Facebook, etc., then you use OAuth2 authentication. As a user, this doesn’t mean much—you just log in to the service. As an engineer, it’s an entirely different perspective.

The first thing to understand is that a user or service account will authenticate using OAuth 2.0 or OpenID Connect against Azure Active Directory (Azure AD)—whether that Azure Active Directory is one maintained by your organization or someone else’s. You can create applications that are intended to be either single-tenant or multi-tenant.

OAuth2 Endpoints

A single-tenant Azure application is designed to be used in a single organization. While a multi-tenant application can be used in any organization—so as long as that organization has pre-authorized the application in their Azure Active Directory (AAD) or consented to an application registration within their AAD.

There are two main endpoints you use to authenticate against Azure Active Directory:

• The v1.0 endpoint only allows users who authenticate using their work or school account.
• The v2.0 endpoint allows work and school accounts, but it also allows the use of personal accounts, such as hotmail.com, outlook.com, live.com, etc.. This is called the COMMON endpoint. You can also authenticate directly to your organization’s tenant here.

The table below explains this in more detail:

Tenant	Account Type	Endpoint URL
Single Tenant	Work/School	https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
Multi-Tenant	Work/School	https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
Single Tenant	Personal	https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
Multi-Tenant	Personal	https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow

Application Types

There are several different application types you can use when you register an application within Azure Active Directory. The application type you create will depend on what your application will be doing, who will be using your application, and which OAuth2 endpoint you will be using.

By visiting Microsoft’s types of applications documentation for the v1.0 and v2.0 endpoint, you can see that there are five primary application scenarios supported by these endpoints:

1. Single-page application (SPA): SPAs typically have a front-end authentication (sign-in) page, but the core of the work is on the backend. This means a user does need to interact and sign-in to your application.
2. Web browser to Web application: This is your typical single sign-on (SSO) application authorization flow. If you have SSO enabled for a service or application, you typically use this type of application.
3. Native application to Web API: If you have a desktop application or a phone or tablet app that needs the user to authenticate before pulling or pushing information to your API, then use this application type.
4. Web application to Web API: If you have a Web app that needs to get resources from either another service you own or from a third-party service/API, then use this type of application.
5. Daemon or service to Web API: If your application is headless and will run in the background but needs access to your API/service, then use this type of application.

Application Scenarios	Application Type	Implicit Grant Flow	Auth Code Grant Flow	On-Behalf-Of Flow	Client Credentials Grant
Single-Page Application	Single-Page Apps	X
Web Browser to Web Application	Web Apps	X	X
Native Application to Web API	Mobile & Native Apps	X	X	x
Web Application to Web API	Web APIs			X	X
Daemon or Service to Web API	Daemons & Server-Side Apps				x

I hope this has helped you understand the different API endpoints and application types you need to consider when using Microsoft OAuth2 authentication schema. In the next post in this series, I will show you to register your application and break-down the different permissions required to retrieve and authenticate using OAuth2.