v2.0 Protocols - OAuth 2.0 and OpenID Connect

The v2.0 endpoint can use Azure Active Directory (Azure AD) for identity-as-a-service with industry standard protocols, OpenID Connect and OAuth 2.0. While the service is standards-compliant, there can be subtle differences between any two implementations of these protocols. The information here will be useful if you choose to write your code by directly sending and handling HTTP requests or use a third party open-source library, rather than using one of our open-source libraries.


Not all Azure AD scenarios and features are supported by the v2.0 endpoint. To determine if you should use the v2.0 endpoint, read about v2.0 limitations.

The basics

In nearly all OAuth 2.0 and OpenID Connect flows, there are four parties involved in the exchange:

OAuth 2.0 Roles

  • The Authorization Server is the v2.0 endpoint and responsible for ensuring the user's identity, granting and revoking access to resources, and issuing tokens. The authorization server also known as the identity provider - it securely handles anything to do with the user's information, their access, and the trust relationships between parties in a flow.
  • The Resource Owner is typically the end user. It's the party that owns the data and has the power to allow third parties to access that data or resource.
  • The OAuth Client is your app, identified by its application ID. The OAuth client is usually the party that the end user interacts with, and it requests tokens from the authorization server. The client must be granted permission to access the resource by the resource owner.
  • The Resource Server is where the resource or data resides. It trusts the Authorization Server to securely authenticate and authorize the OAuth Client, and uses Bearer access_tokens to ensure that access to a resource can be granted.

App Registration

Every app that uses the v2.0 endpoint must be registered in apps.dev.microsoft.com or through the new App registrations (Preview) experience in the Azure portal before it can interact using OAuth or OpenID Connect. The app registration process will collect and assign a few values to your app:

  • An Application ID that uniquely identifies your app
  • A Redirect URI or Package Identifier that can be used to direct responses back to your app
  • A few other scenario-specific values.

For more details, learn how to register an app.


Once registered, the app communicates with Azure AD by sending requests to the v2.0 endpoint:


Where the {tenant} can take one of four different values:

Value Description
common Allows users with both personal Microsoft accounts and work/school accounts from Azure AD to sign into the application.
organizations Allows only users with work/school accounts from Azure AD to sign into the application.
consumers Allows only users with personal Microsoft accounts (MSA) to sign into the application.
8eaef023-2b34-4da1-9baa-8bc8c9d6a490 or contoso.onmicrosoft.com Allows only users with work/school accounts from a particular Azure AD tenant to sign into the application. Either the friendly domain name of the Azure AD tenant or the tenant's GUID identifier can be used.

To learn how to interact with these endpoints, choose a particular app type in the Protocols section and follow the links for more info.


The v2.0 implementation of OAuth 2.0 and OpenID Connect make extensive use of bearer tokens, including bearer tokens represented as JWTs. A bearer token is a lightweight security token that grants the “bearer” access to a protected resource. In this sense, the “bearer” is any party that can present the token. Though a party must first authenticate with Azure AD to receive the bearer token, if the required steps are not taken to secure the token in transmission and storage, it can be intercepted and used by an unintended party. While some security tokens have a built-in mechanism for preventing unauthorized parties from using them, bearer tokens do not have this mechanism and must be transported in a secure channel such as transport layer security (HTTPS). If a bearer token is transmitted in the clear, a malicious party can use a man-in-the-middle attack to acquire the token and use it for unauthorized access to a protected resource. The same security principles apply when storing or caching bearer tokens for later use. Always ensure that your app transmits and stores bearer tokens in a secure manner. For more security considerations on bearer tokens, see RFC 6750 Section 5.

Further details of different types of tokens used in the v2.0 endpoint is available in the v2.0 endpoint token reference.


If you're ready to see some example requests, get started with one of the below tutorials. Each one corresponds to a particular authentication scenario. If you need help determining which is the right flow for you, check out the types of apps you can build with the v2.0.