Overview:
Some organizations set goals to remove Active Directory and their on-premises IT footprint. Others take advantage of some cloud-based capabilities to reduce the Active Directory footprint, but not to completely remove their on-premises environments.
This content provides guidance to move:
- From Active Directory and other non-cloud-based services, either on-premises or infrastructure as a service (IaaS), that provide identity management (IDM), identity and access management (IAM), and device management.
- To Microsoft Entra ID and other Microsoft cloud-native solutions for IDM, IAM, and device management.
Transformation must be aligned with and achieve business objectives, including increased productivity, reduced costs and complexity, and improved security posture
Applications
To help maintain a secure environment, Microsoft Entra ID supports modern authentication protocols.
To transition application authentication from Active Directory to Microsoft Entra ID, you must:
- Determine which applications can migrate to Microsoft Entra ID with no modification.
- Determine which applications have an upgrade path that enables you to migrate with an upgrade.
- Determine which applications require replacement or significant code changes to migrate.
The outcome of your application discovery initiative is to create a prioritized list for migrating your application portfolio. The list contains applications that:
- Require an upgrade or update to the software, and an upgrade path is available.
- Require an upgrade or update to the software, but an upgrade path isn’t available.
By using the list, you can further evaluate the applications that don’t have an existing upgrade path. Determine whether business value warrants updating the software or if it should be retired. If the software should be retired, decide whether you need a replacement.
Based on the results, you might redesign aspects of your transformation from Active Directory to Microsoft Entra ID. There are approaches that you can use to extend on-premises Active Directory to Azure infrastructure as a service (IaaS) (lift and shift) for applications with unsupported authentication protocols. We recommend that you set a policy that requires an exception to use this approach.
Application discovery
After you’ve segmented your app portfolio, you can prioritize migration based on business value and business priority. You can use tools to create or refresh your app inventory.
There are three main ways to categorize your apps:
1. Modern authentication apps:
- These applications use modern authentication protocols (such as OIDC, OAuth2, SAML, or WS-Federation) or that use a federation service such as Active Directory Federation Services (AD FS).
2. Web access management (WAM) tools:
- These applications use headers, cookies, and similar techniques for SSO. These apps typically require a WAM identity provider, such as Symantec SiteMinder.
3. Legacy apps:
- These applications use legacy protocols such as Kerberos, LDAP, Radius, Remote Desktop, and NTLM (not recommended).
The Microsoft identity platform supports authentication for various modern app architectures, all of them based on industry-standard protocols OAuth 2.0 or OpenID Connect.
This article describes the types of apps that you can build by using Microsoft identity platform, regardless of your preferred language or platform.
The information is designed to help you understand high-level scenarios before you start working with the code in the application scenarios.
The basics
You must register each app that uses the Microsoft identity platform in the Microsoft Entra admin center App registrations.
The app registration process collects and assigns these values for your app:
- An Application (client) ID that uniquely identifies your app
- A Redirect URI that you can use to direct responses back to your app
- A few other scenario-specific values such as supported account types
For details, check how to register an app.
<Add Rajeev post> Enable (Only) built-in Auth/Add app authentication to your web app running on Azure App Service)
After the app is registered, the app communicates with the Microsoft identity platform by sending requests to the endpoint.
We provide open-source frameworks and libraries that handle the details of these requests.
You also have the option to implement the authentication logic yourself by creating requests to these endpoints:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
The app types supported by the Microsoft identity platform are;
- Single-page app (SPA)
- Web app
- Web API
- Mobile and native apps
- Service, daemon, script
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
Summary of App types and Protocols used:
Below is a summary what kind of Protocols to be used for these App types:
| LAB# | App Type | Protocol | Supported Grant Types |
| 1 | Enable built in Auth | Built in | |
| 2 | .NET, PHP, Java, Ruby, Python, Node ASP.net Core | OpenID connect | authorization code flow and call the Microsoft Graph API |
| 3 | ASP.net Framework | OWIN | |
| 4 | .NET, PHP, Java, Ruby, Python, Node + API | OpenID Connect + OAuth2 Flow | OAuth 2.0 authorization code flow |
| 5 | Web API | ||
| 6 | SPA Angular, React, or Vue | OpenID connect | OAuth 2.0 implicit grant flow or the more recent OAuth 2.0 authorization code + PKCE flow |
Details of Each App Types
(1) Single-page apps
Many modern apps have a single-page app (SPA) front end written primarily in JavaScript, often with a framework like Angular, React, or Vue.
The Microsoft identity platform supports these apps by using the OpenID Connect protocol for authentication and one of two types of authorization grants defined by OAuth 2.0.
What is OpenID Connect?
OpenID Connect (OIDC) extends the OAuth 2.0 authorization protocol for use as an additional authentication protocol. You can use OIDC to enable single sign-on (SSO) between your OAuth-enabled applications by using a security token called an ID token.
The supported grant types are either the OAuth 2.0 implicit grant flow or the more recent OAuth 2.0 authorization code + PKCE flow (see below).
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
The flow diagram demonstrates the OAuth 2.0 authorization code grant flow (with details around PKCE omitted), where the app receives a code from the Microsoft identity platform authorize endpoint, and redeems it for an access token and a refresh token using cross-site web requests.
For SPAs, the access token is valid for 1 hour, and once expired, must request another code using the refresh token.
In addition to the access token, an id_token that represents the signed-in user to the client application is typically also requested through the same flow and/or a separate OpenID Connect request (not shown here).
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
LAB#
Open 1-Authentication/1-sign-in/App/authConfig.js
const msalConfig = { auth: {
clientId: ‘Enter_the_Application_Id_Here’, // This is the ONLY mandatory field that you need to supply.
authority: ‘https://login.microsoftonline.com/Enter_the_Tenant_Info_Here‘, // Defaults to “https://login.microsoftonline.com/common“
redirectUri: ‘Enter_the_Redirect_URI_Here/’, // You must register this URI in the app registration on the Microsoft Entra admin center. Defaults to window.location.href e.g. http://localhost:3000/ navigateToLoginRequestUrl: true, // If “true”, will navigate back to the original request location before processing the auth code response. },
Authorization code flow vs. implicit flow
The OAuth 2.0 authorization code flow is now the recommended way to build SPAs to ensure compatibility of your app in Safari and other privacy-conscious browsers.
Following the removal of third-party cookies and greater attention, the continued use of the implicit flow is not recommended.
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
What is third party cookies blocking?
Many browsers block third-party cookies, cookies on requests to domains other than the domain shown in the browser’s address bar. These cookies are also known as cross-domain cookies. This block breaks the implicit flow and requires new authentication patterns to successfully sign in users. In the Microsoft identity platform, we use the authorization flow with Proof Key for Code Exchange (PKCE) and refresh tokens to keep users signed in when third-party cookies are blocked.
From <https://learn.microsoft.com/en-us/entra/identity-platform/reference-third-party-cookies-spas>
(2) Web apps
For web apps (.NET, PHP, Java, Ruby, Python, Node) that the user accesses through a browser, you can use OpenID Connect for user sign-in.
In OpenID Connect, the web app receives an ID token.
An ID token is a security token that verifies the user’s identity and provides information about the user in the form of claims:
JSONCopy
// Partial raw ID token
abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9…
// Partial content of a decoded ID token
{
“name”: “Casey Jensen”,
“email”: “casey.jensen@onmicrosoft.com”,
“oid”: “ab12cd34-effe-5678-9012-abcdef012345″…
}
Further details of different types of tokens used in the Microsoft identity platform are available in the access token reference and id_token reference.
In web server apps, the sign-in authentication flow takes these high-level steps:
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
You can ensure the user’s identity by validating the ID token with a public signing key that is received from the Microsoft identity platform. A session cookie is set, which can be used to identify the user on subsequent page requests.
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
LAB# Web app that signs in users – Overview – Microsoft identity platform | Microsoft Learn
(3). Web APP + API
In addition to simple sign-in, a web server app might need to access another web service, such as a Representational State Transfer (REST) API. In this case, the web server app engages in a combined OpenID Connect and OAuth 2.0 flow, by using the OAuth 2.0 authorization code flow. For more information about this scenario, refer to our code sample.
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
Overview
This sample demonstrates an ASP.NET Core web app that calls the Microsoft Graph API for a signed-in user.
Scenario
- The ASP.NET Core client web app uses the Microsoft.Identity.Web to sign a user in, and obtain a JWT access Tokens from Microsoft Entra ID.
- The access token is used by the client app as a bearer token to call Microsoft Graph.
Prerequisites
- Either Visual Studio or Visual Studio Code and .NET Core SDK
- An Microsoft Entra ID tenant. For more information see: How to get a Microsoft Entra tenant
- A user account in your Microsoft Entra ID tenant. This sample will not work with a personal Microsoft account. If you’re signed in to the Microsoft Entra admin center with a personal account and have not created a user account in your directory before, you will need need to create one before proceeding.
(4) Web APIs
You can use the Microsoft identity platform to secure web services, such as your app’s RESTful web API.
Web APIs can be implemented in numerous platforms and languages.
They can also be implemented using HTTP Triggers in Azure Functions.
Instead of ID tokens and session cookies, a web API uses an OAuth 2.0 access token to secure its data and to authenticate incoming requests.
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
The caller of a web API appends an access token in the authorization header of an HTTP request, like this:
GET/api/itemsHTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9…
Accept: application/json
…
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
The web API uses the access token to verify the API caller’s identity and to extract information about the caller from claims that are encoded in the access token
A web API can give users the power to opt in or opt out of specific functionality or data by exposing permissions, also known as scopes.
For a calling app to acquire permission to a scope, the user must consent to the scope during a flow.
The Microsoft identity platform asks the user for permission, and then records permissions in all access tokens that the web API receives.
The web API validates the access tokens it receives on each call and performs authorization checks.
A web API can receive access tokens from all types of apps, including web server apps, desktop and mobile apps, single-page apps, server-side daemons, and even other web APIs.
The high-level flow for a web API looks like this:
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
To learn how to secure a web API by using OAuth2 access tokens, check out the web API code samples in the protected web API scenario.
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
LAB# Protected web API – Overview – Microsoft identity platform | Microsoft Learn
Register App
Code configuration (Set the bearer token in header, JwtBearer configuration, Add Audience property with App ID, C# code changes)
Verification of scopes or app roles
Move to production
(5) Mobile and native apps
Device-installed apps, such as mobile and desktop apps, often need to access back-end services or web APIs that store data and perform functions on behalf of a user. These apps can add sign-in and authorization to back-end services by using the OAuth 2.0 authorization code flow.
In this flow, the app receives an authorization code from the Microsoft identity platform when the user signs in. The authorization code represents the app’s permission to call back-end services on behalf of the user who is signed in. The app can exchange the authorization code in the background for an OAuth 2.0 access token and a refresh token. The app can use the access token to authenticate to web APIs in HTTP requests, and use the refresh token to get new access tokens when older access tokens expire.
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
(6) Server, daemons and scripts
Apps that have long-running processes or that operate without interaction with a user also need a way to access secured resources, such as web APIs. These apps can authenticate and get tokens by using the app’s identity, rather than a user’s delegated identity, with the OAuth 2.0 client credentials flow. You can prove the app’s identity using a client secret or certificate. For more info, see .NET daemon console application using Microsoft identity platform.
In this flow, the app interacts directly with the /token endpoint to obtain access:
From <https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types>
Recap:
Summary: Application Types for the Microsoft Identity Platform
The Microsoft identity platform offers authentication solutions for various modern app architectures, all based on industry-standard protocols like OAuth 2.0 and OpenID Connect. Here are the key app types:
- Single-Page Apps (SPAs):
- SPAs have a front end written primarily in JavaScript (e.g., Angular, React, or Vue).
- Use OpenID Connect for authentication and OAuth 2.0 implicit grant or authorization code + PKCE flow.
- Access tokens are valid for 1 hour, and SPAs can request a new code using the refresh token.
- Commonly used for web-based applications.
- Web Apps:
- Traditional web applications that call APIs.
- Authenticate users and access resources using OAuth 2.0 and OpenID Connect.
- Ideal for scenarios where user interaction is required.
- Web APIs:
- APIs that provide services to other apps.
- Authenticate incoming requests using OAuth 2.0 bearer tokens.
- Used for exposing functionality to other applications.
- Mobile and Native Apps:
- Mobile apps (iOS, Android) or native desktop apps.
- Authenticate users using OAuth 2.0 authorization code flow.
- Obtain access tokens and refresh tokens for API access.
- Service, Daemon, and Script Apps:
- Backend services, daemons, or scripts.
- Authenticate using OAuth 2.0 client credentials flow.
- Useful for background tasks or headless processes.
Conclusion
The Microsoft identity platform provides a flexible authentication framework for developers, supporting a wide range of app types. Whether building SPAs, web apps, APIs, or mobile/desktop apps, developers can leverage the platform’s features, libraries, and endpoints to secure their applications effectively