{
	"id": "57350273-7d17-4aad-b2fa-9e49a6341fe4",
	"created_at": "2026-04-06T00:06:20.076997Z",
	"updated_at": "2026-04-10T03:21:25.035183Z",
	"deleted_at": null,
	"sha1_hash": "4e528ebd2a05cdedb5978083bd0dfdfd3afceecf",
	"title": "OAuth 2.0 and OpenID Connect protocols - Microsoft identity platform",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 89982,
	"plain_text": "OAuth 2.0 and OpenID Connect protocols - Microsoft identity\r\nplatform\r\nBy henrymbuguakiarie\r\nArchived: 2026-04-05 16:15:01 UTC\r\nKnowing about OAuth or OpenID Connect (OIDC) at the protocol level isn't required to use the Microsoft identity\r\nplatform. However, you'll encounter protocol terms and concepts as you use the identity platform to add\r\nauthentication to your apps. As you work with the Microsoft Entra admin center, our documentation, and\r\nauthentication libraries, knowing some fundamentals can assist your integration and overall experience.\r\nRoles in OAuth 2.0\r\nFour parties are generally involved in an OAuth 2.0 and OpenID Connect authentication and authorization\r\nexchange. These exchanges are often called authentication flows or auth flows.\r\nMicrosoft\r\nidentity\r\nplatform\r\nResource\r\nserver\r\nResource\r\nowner\r\nBearer\r\nC token lient\r\nAuthorization server\r\nhttps://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols\r\nPage 1 of 4\n\nAuthorization server - The Microsoft identity platform is the authorization server. Also called an identity\r\nprovider or IdP, it securely handles the end-user's information, their access, and the trust relationships\r\nbetween the parties in the auth flow. The authorization server issues the security tokens your apps and APIs\r\nuse for granting, denying, or revoking access to resources (authorization) after the user has signed in\r\n(authenticated).\r\nClient - The client in an OAuth exchange is the application requesting access to a protected resource. The\r\nclient could be a web app running on a server, a single-page web app running in a user's web browser, or a\r\nweb API that calls another web API. You'll often see the client referred to as client application, application,\r\nor app.\r\nResource owner - The resource owner in an auth flow is usually the application user, or end-user in OAuth\r\nterminology. The end-user \"owns\" the protected resource (their data) which your app accesses on their\r\nbehalf. The resources owners can grant or deny your app (the client) access to the resources they own. For\r\nexample, your app might call an external system's API to get a user's email address from their profile on\r\nthat system. Their profile data is a resource the end-user owns on the external system, and the end-user can\r\nconsent to or deny your app's request to access their data.\r\nResource server - The resource server hosts or provides access to a resource owner's data. Most often, the\r\nresource server is a web API fronting a data store. The resource server relies on the authorization server to\r\nperform authentication and uses information in bearer tokens issued by the authorization server to grant or\r\ndeny access to resources.\r\nTokens\r\nThe parties in an authentication flow use bearer tokens to assure, verify, and authenticate a principal (user, host,\r\nor service) and to grant or deny access to protected resources (authorization). Bearer tokens in the Microsoft\r\nidentity platform are formatted as JSON Web Tokens (JWT).\r\nThree types of bearer tokens are used by the identity platform as security tokens:\r\nAccess tokens - Access tokens are issued by the authorization server to the client application. The client\r\npasses access tokens to the resource server. Access tokens contain the permissions the client has been\r\ngranted by the authorization server.\r\nID tokens - ID tokens are issued by the authorization server to the client application. Clients use ID tokens\r\nwhen signing in users and to get basic information about them.\r\nRefresh tokens - The client uses a refresh token, or RT, to request new access and ID tokens from the\r\nauthorization server. Your code should treat refresh tokens and their string content as sensitive data because\r\nthey're intended for use only by authorization server.\r\nApp registration\r\nYour client app needs a way to trust the security tokens issued to it by the Microsoft identity platform. The first\r\nstep in establishing trust is by registering your app. When you register your app, the identity platform\r\nhttps://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols\r\nPage 2 of 4\n\nautomatically assigns it some values, while others you configure based on the application's type.\r\nTwo of the most commonly referenced app registration settings are:\r\nApplication (client) ID - Also called application ID and client ID, this value is assigned to your app by the\r\nidentity platform. The client ID uniquely identifies your app in the identity platform and is included in the\r\nsecurity tokens the platform issues.\r\nRedirect URI - The authorization server uses a redirect URI to direct the resource owner's user-agent (web\r\nbrowser, mobile app) to another destination after completing their interaction. For example, after the end-user authenticates with the authorization server. Not all client types use redirect URIs.\r\nYour app's registration also holds information about the authentication and authorization endpoints you'll use in\r\nyour code to get ID and access tokens.\r\nEndpoints\r\nThe Microsoft identity platform offers authentication and authorization services using standards-compliant\r\nimplementations of OAuth 2.0 and OpenID Connect (OIDC) 1.0. Standards-compliant authorization servers like\r\nthe identity platform provide a set of HTTP endpoints for use by the parties in an auth flow to execute the flow.\r\nThe endpoint URIs for your app are generated automatically when you register or configure your app. The\r\nendpoints you use in your app's code depend on the application's type and the identities (account types) it should\r\nsupport.\r\nTwo commonly used endpoints are the authorization endpoint and token endpoint. Here are examples of the\r\nauthorize and token endpoints:\r\n# Authorization endpoint - used by client to obtain authorization from the resource owner.\r\nhttps://login.microsoftonline.com/\u003cissuer\u003e/oauth2/v2.0/authorize\r\n# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.\r\nhttps://login.microsoftonline.com/\u003cissuer\u003e/oauth2/v2.0/token\r\n# NOTE: These are examples. Endpoint URI format may vary based on application type,\r\n# sign-in audience, and Azure cloud instance (global or national cloud).\r\n# The {issuer} value in the path of the request can be used to control who can sign into the application.\r\n# The allowed values are **common** for both Microsoft accounts and work or school accounts,\r\n# **organizations** for work or school accounts only, **consumers** for Microsoft accounts only,\r\n# and **tenant identifiers** such as the tenant ID or domain name.\r\nTo find the endpoints for an application you've registered, in the Microsoft Entra admin center navigate to:\r\nEntra ID \u003e App registrations \u003e \u003cYOUR-APPLICATION\u003e \u003e Endpoints\r\nNext steps\r\nhttps://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols\r\nPage 3 of 4\n\nNext, learn about the OAuth 2.0 authentication flows used by each application type and the libraries you can use\r\nin your apps to perform them:\r\nAuthentication flows and application scenarios\r\nMicrosoft Authentication Library (MSAL)\r\nWe strongly advise against crafting your own library or raw HTTP calls to execute authentication flows. A\r\nMicrosoft Authentication Library is safer and easier. However, if your scenario prevents you from using our\r\nlibraries or you'd just like to learn more about the Microsoft identity platform's implementation, we have protocol\r\nreference:\r\nAuthorization code grant flow - Single-page apps (SPA), mobile apps, native (desktop) applications\r\nClient credentials flow - Server-side processes, scripts, daemons\r\nOn-behalf-of (OBO) flow - Web APIs that call another web API on a user's behalf\r\nOpenID Connect - User sign-in, sign out, and single sign-on (SSO)\r\nSource: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols\r\nhttps://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols"
	],
	"report_names": [
		"active-directory-v2-protocols"
	],
	"threat_actors": [],
	"ts_created_at": 1775433980,
	"ts_updated_at": 1775791285,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4e528ebd2a05cdedb5978083bd0dfdfd3afceecf.pdf",
		"text": "https://archive.orkl.eu/4e528ebd2a05cdedb5978083bd0dfdfd3afceecf.txt",
		"img": "https://archive.orkl.eu/4e528ebd2a05cdedb5978083bd0dfdfd3afceecf.jpg"
	}
}