Azure PaaS
Authentication scenarios and recommendations
Overview:
In this post we will talk about Authentication scenarios and recommendations.
If you have a web app or an API running in Azure App Service, you can restrict access to it based on the identity of the users or applications that request it.
App Service offers several authentication solutions to help you achieve this goal.
In this post, we will explore the different authentication options, their benefits and drawbacks, and which authentication solution to use for specific scenarios.
Authentication solutions
1. Azure App Service built-in authentication
- Allows you to sign users in and access data by writing minimal or no code in your web app, RESTful API, or mobile back end.
- It’s built directly into the platform and doesn’t require any particular language, library, security expertise, or even any code to use.
2. Microsoft Authentication Library (MSAL)
- Enables developers to acquire security tokens from the Microsoft identity platform to authenticate users and access secured web APIs.
- Available for multiple supported platforms and frameworks, these are general purpose libraries that can be used in various hosted environments.
- Developers can also integrate with multiple sign-in providers, like Microsoft Entra ID, Facebook, Google, Twitter. (B2C scenarios)
- Note: Earlier ADAL was used which is now deprecated.
3. Microsoft.Identity.Web
- A higher-level library wrapping MSAL.NET, it provides a set of ASP.NET Core abstractions that simplify adding authentication support to web apps and web APIs integrating with the Microsoft identity platform.
- It provides a single-surface API convenience layer that ties together ASP.NET Core, its authentication middleware, and MSAL.NET.
- This library can be used in apps in various hosted environments.
- You can integrate with multiple sign-in providers, like Microsoft Entra ID, Facebook, Google, Twitter.
Microsoft.Identity.Web provides the glue between ASP.NET Core, the authentication middleware, and the Microsoft Authentication Library (MSAL) for .NET. It allows for a clearer, more robust developer experience and leverages the power of the Microsoft identity platform and Azure AD B2C.
What is MSAL and Microsoft.Identity.Web ?
MSAL (Microsoft Authentication Library) and Microsoft.Identity.Web are both libraries that enable developers to acquire tokens from the Microsoft identity platform endpoint in order to access secured web APIs. However, they have some differences in their features and functionalities.
MSAL is a cross-platform library that supports various application types, such as web apps, web APIs, mobile apps, desktop apps, and browser-based apps. MSAL also supports various authentication flows, such as interactive, integrated Windows, device code, username/password, and more. MSAL can be used with any identity provider that supports OpenID Connect, such as Azure AD, Azure AD B2C, or Azure AD B2B.
Microsoft.Identity.Web is a library that is specific to ASP.NET Core web apps and web APIs. It is built on top of MSAL and provides additional features and conveniences for ASP.NET Core developers, such as dependency injection, configuration, cookie management, token cache serialization, and more. Microsoft.Identity.Web also simplifies the integration with other Microsoft services and libraries, such as Microsoft Graph, Azure Key Vault, Azure App Configuration, and Microsoft.IdentityModel.
Scenario recommendations
The following table lists each authentication solution and some important factors for when you would use it.
| Authentication method | When to use |
| (1) Built-in App Service authentication | You want less code to own and manage. Your app’s language and SDKs don’t provide user sign-in or authorization. You don’t have the ability to modify your app code (for example, when migrating legacy apps). You need to handle authentication through configuration and not code. You need to sign in external or social users. |
| (2) Microsoft Authentication Library (MSAL) | You need a code solution in one of several different languagesYou need to add custom authorization logic.(e.g, <>) You need to support incremental consent.(e.g, <>) You need information about the signed-in user in your code. You need to sign in external or social users. Your app needs to handle the access token expiring without making the user sign in again. |
| (3) Microsoft.Identity.Web | You have an ASP.NET Core app. You need single sign-on support in your IDE during local development. You need to add custom authorization logic. You need to support incremental consent. You need conditional access in your web app. You need information about the signed-in user in your code. You need to sign in external or social users. Your app needs to handle the access token expiring without making the user sign in again. |
Best practices
Regardless of the configuration you use to set up authentication, the following best practices will keep your tenant and applications more secure:
Configure each App Service app with its own app registration in Microsoft Entra ID.
- Give each App Service app its own permissions and consent.
- Avoid permission sharing between environments by using separate app registrations for separate deployment slots.
- When you’re testing new code, this practice can help prevent issues from affecting the production app.
Starting June 30th, 2020 we will no longer add any new features to Azure Active Directory Authentication Library (ADAL) and Azure Active Directory Graph. We will continue to provide technical support and security updates but we will no longer provide feature updates. Applications will need to be upgraded to Microsoft Authentication Library (MSAL) and Microsoft Graph. Learn more
Categorize your application and protocol selection?
There are three main ways to categorize your apps:
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).
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.
Legacy apps:
- These applications use legacy protocols such as Kerberos, LDAP, Radius, Remote Desktop, and NTLM (not recommended).
Understanding Authentication protocols:
What is Open ID?
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.
Overview: OIDC, OAuth2, SAML, WS-Federation
| Protocol | Description | Use case | Flow | Sample |
| OIDC | OpenID Connect is an identity layer on top of OAuth2 that enables clients to verify the identity of the end-user and obtain basic profile information. | Suitable for web, mobile, and native applications that need to authenticate users and access their identity information. | The client sends an authentication request to the authorization server with the scope=openid parameter. The authorization server redirects the user to the client with an ID token and an optional access token. The client validates the ID token and extracts the user information. | Google, Microsoft, and Facebook provide OIDC services that allow users to sign in with their accounts. |
| OAuth2 | OAuth2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, or Google. | Suitable for web, mobile, and native applications that need to access protected resources on behalf of the user. | The client sends an authorization request to the authorization server with the response_type parameter. The authorization server redirects the user to the client with an authorization code or an access token. The client exchanges the code for an access token and a refresh token using its client secret. The client uses the access token to access the protected resource and the refresh token to obtain new access tokens. | Spotify, Twitter, and GitHub use OAuth2 to allow users to grant access to their accounts and data. |
| SAML | Security Assertion Markup Language is an XML-based standard for exchanging authentication and authorization data between an identity provider and a service provider. | Suitable for web-based single sign-on scenarios where the user logs in once at the identity provider and can access multiple service providers. | The user requests a service from the service provider. The service provider redirects the user to the identity provider with a SAML request. The identity provider authenticates the user and sends a SAML response with an assertion to the service provider. The service provider validates the assertion and grants access to the user. | Okta, OneLogin, and Ping Identity offer SAML services that enable users to access multiple applications with one login. |
| WS-Federation | Web Services Federation is a protocol that allows different security realms to federate, or trust each other, using tokens. | Suitable for web-based single sign-on scenarios where the user logs in once at the identity provider and can access multiple relying parties. | The user requests a service from the relying party. The relying party redirects the user to the identity provider with a WS-Federation request. The identity provider authenticates the user and sends a WS-Federation response with a token to the relying party. The relying party validates the token and grants access to the user. | Microsoft Azure Active Directory, IBM Tivoli Federated Identity Manager, and Oracle Access Manager support WS-Federation for federated identity management. |
Difference Open ID vs OAUth2?
Here is a table that summarizes the differences between OpenID Connect and OAuth:
| Aspect | OpenID Connect | OAuth |
| Definition | A protocol that extends OAuth and adds an identity layer on top of it. It allows a user to sign in to a third-party application using their existing account on another service. | A protocol that allows a user to grant a third-party application access to their resources on another service. |
| Features | – Provides information about the user’s identity, such as their name, email, profile picture, and more. – Supports various authentication methods, such as password, biometric, or multi-factor. – Defines standard scopes and claims for identity information. – Uses JSON Web Tokens (JWT) to encode the identity information. | – Provides tokens that represent the user’s permission to access their resources. – Supports various authorization flows, such as authorization code, implicit, client credentials, or resource owner password. – Defines standard scopes for access levels. – Uses opaque tokens or JWT to encode the access information. |
| When to use | – When you want to enable user authentication for your application. – When you want to leverage the existing identity providers, such as Google, Facebook, or Twitter. – When you want to access identity-related APIs, such as Microsoft Graph, Google People, or Facebook Graph. | – When you want to enable access delegation for your application. – When you want to access resource-related APIs, such as Google Drive, Dropbox, or Twitter. – When you want to implement your own identity provider or resource server. |
| When not to use | – When you only need to access resources, not identity information. – When you have your own user database and authentication mechanism. – When you do not want to rely on third-party identity providers. | – When you only need to authenticate users, not access resources. – When you do not have your own resource server or API. – When you do not want to rely on third-party authorization servers. |
Difference ADAL VS MSAL?
| ADAL | MSAL |
| Azure Active Directory Authentication Library | Microsoft Authentication Library |
| Supports Azure AD v1.0 endpoint | Supports Azure AD v2.0 and Azure AD B2C endpoints |
| Allows sign in with work and school accounts | Allows sign in with work and school accounts, personal Microsoft accounts, and social accounts |
| Older and less performant library | Newer and more performant library |
| Does not support conditional access, certificate-based authentication, and b2b collaboration | Supports conditional access, certificate-based authentication, and b2b collaboration |
| Will be deprecated in the future | Recommended for new and existing projects |
You should use ADAL only if you have a legacy application that cannot be migrated to MSAL, or if you need to access resources that are not supported by the Azure AD v2.0 endpoint, such as SharePoint Online or Exchange Online.
You should not use ADAL for new projects, or if you want to leverage the latest features and scenarios that MSAL offers.
You should use MSAL if you want to access resources that are supported by the Azure AD v2.0 endpoint, such as Microsoft Graph or your own web APIs. You should also use MSAL if you want to sign in users with different types of accounts, or if you want to use advanced features such as conditional access, certificate-based authentication, and b2b collaboration. You should not use MSAL if you need to access resources that are not supported by the Azure AD v2.0 endpoint, such as SharePoint Online or Exchange Online.
If you want to try some lab samples that demonstrate how to use ADAL and MSAL, you can check out these links:
- ADAL samples: https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/tree/dev/samples
- MSAL samples: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/tree/master/samples
What’s the difference between Azure AD v1.0 endpoint and Azure AD v2.0 endpoint
| Feature/ Limitation | Azure AD v1.0 endpoint | Azure AD v2.0 endpoint |
| Supported account types | Work and school accounts only | Work and school accounts, personal Microsoft accounts, and social accounts |
| Supported resources | Resources registered in Azure AD, such as Office 365, SharePoint Online, Exchange Online, etc. | Resources registered in the Microsoft identity platform, such as Microsoft Graph, your own web APIs, etc. |
| Supported protocols | SAML, WS-Federation, OAuth 1.0, OAuth 2.0, and OpenID Connect | OAuth 2.0 and OpenID Connect only |
| Scopes and permissions | Azure AD Graph permissions and resource-specific permissions | Microsoft Graph permissions only |
| Dynamic consent | Not supported | Supported |
| Incremental consent | Not supported | Supported |
| Conditional access | Not supported | Supported |
| Certificate-based authentication | Not supported | Supported |
| B2B collaboration | Not supported | Supported |
App Types and Auth Flow
The Microsoft identity platform supports authentication for different kinds of modern application architectures. All of the architectures are based on the industry-standard protocols OAuth 2.0 and OpenID Connect.
By using the authentication libraries for the Microsoft identity platform, applications authenticate identities and acquire tokens to access protected APIs.
Application categories
Security tokens can be acquired from several types of applications, including:
- Web apps
- Mobile apps
- Desktop apps
- Web APIs
Tokens can also be acquired by apps running on devices that don’t have a browser or are running on the Internet of Things (IoT).
The following sections describe the categories of applications.
Protected resources vs. client applications
Authentication scenarios involve two activities:
- Acquiring security tokens for a protected web API: We recommend that you use the Microsoft Authentication Library (MSAL), developed and supported by Microsoft.
- Protecting a web API or a web app: One challenge of protecting these resources is validating the security token. On some platforms, Microsoft offers middleware libraries.
From <https://learn.microsoft.com/en-us/entra/identity-platform/authentication-flows-app-scenarios>
With users or without users
Most authentication scenarios acquire tokens on behalf of signed-in users.
However, there are also daemon apps. In these scenarios, applications acquire tokens on behalf of themselves with no user.
From <https://learn.microsoft.com/en-us/entra/identity-platform/authentication-flows-app-scenarios>
Single-page, public client, and confidential client applications
Security tokens can be acquired by multiple types of applications. These applications tend to be separated into the following three categories. Each is used with different libraries and objects.
Single-page applications:
- Also known as SPAs, these are web apps in which tokens are acquired by a JavaScript or TypeScript app running in the browser. Many modern apps have a single-page application at the front end that’s primarily written in JavaScript. The application often uses a framework like Angular, React, or Vue. MSAL.js is the only Microsoft Authentication Library that supports single-page applications.
Public client applications:
- Apps in this category, like the following types, always sign in users:
- Desktop apps that call web APIs on behalf of signed-in users
- Mobile apps
- Apps running on devices that don’t have a browser, like those running on IoT
Confidential client applications:
- Apps in this category include:
- Web apps that call a web API
- Web APIs that call a web API
- Daemon apps, even when implemented as a console service like a Linux daemon or a Windows service
From <https://learn.microsoft.com/en-us/entra/identity-platform/authentication-flows-app-scenarios>
Application types
The Microsoft identity platform supports authentication for these app architectures:
- Single-page apps
- Web apps
- Web APIs
- Mobile apps
- Native apps
- Daemon apps
- Server-side apps
Applications use the different authentication flows to sign in users and get tokens to call protected APIs.
Single-page application
Many modern web apps are built as client-side single-page applications. These applications use JavaScript or a framework like Angular, Vue, and React. These applications run in a web browser.
Single-page applications differ from traditional server-side web apps in terms of authentication characteristics. By using the Microsoft identity platform, single-page applications can sign in users and get tokens to access back-end services or web APIs.
The Microsoft identity platform offers two grant types for JavaScript applications:
Web app that signs in a user
To help protect a web app that signs in a user:
- If you develop in .NET, you use ASP.NET or ASP.NET Core with the ASP.NET OpenID Connect middleware. Protecting a resource involves validating the security token, which is done by the IdentityModel extensions for .NET and not MSAL libraries.
- If you develop in Node.js, you use MSAL Node.
Web app that signs in a user and calls a web API on behalf of the user.
To call a web API from a web app on behalf of a user, use the authorization code flow and store the acquired tokens in the token cache. When needed, MSAL refreshes tokens and the controller silently acquires tokens from the cache.
For more information, see Web app that calls web APIs.
Desktop app that calls a web API on behalf of a signed-in user
For a desktop app to call a web API that signs in users, use the interactive token-acquisition methods of MSAL. With these interactive methods, you can control the sign-in UI experience. MSAL uses a web browser for this interaction.
There’s another possibility for Windows-hosted applications on computers joined either to a Windows domain or by Microsoft Entra ID. These applications can silently acquire a token by using integrated Windows authentication.
Applications running on a device without a browser can still call an API on behalf of a user. To authenticate, the user must sign in on another device that has a web browser. This scenario requires that you use the device code flow.
Though we don’t recommend that you use it, the username/password flow is available in public client applications. This flow is still needed in some scenarios like DevOps.
Using the username/password flow constrains your applications. For instance, applications can’t sign in a user who needs to use multifactor authentication or the Conditional Access tool in Microsoft Entra ID. Your applications also don’t benefit from single sign-on. Authentication with the username/password flow goes against the principles of modern authentication and is provided only for legacy reasons.
In desktop apps, if you want the token cache to persist, you can customize the token cache serialization. By implementing dual token cache serialization, you can use backward-compatible and forward-compatible token caches.
For more information, see Desktop app that calls web APIs.
Mobile app that calls a web API on behalf of an interactive user
Similar to a desktop app, a mobile app calls the interactive token-acquisition methods of MSAL to acquire a token for calling a web API.
MSAL iOS and MSAL Android use the system web browser by default. However, you can direct them to use the embedded web view instead. There are specificities that depend on the mobile platform: Universal Windows Platform (UWP), iOS, or Android.
From <https://learn.microsoft.com/en-us/entra/identity-platform/authentication-flows-app-scenarios>
| Scenario | Detailed scenario walk-through | OAuth 2.0 flow and grant | Audience |
| Single-page app | Authorization code with PKCE | Work or school accounts, personal accounts, and Azure Active Directory B2C (Azure AD B2C) | |
| Single-page app | Implicit | Work or school accounts, personal accounts, and Azure Active Directory B2C (Azure AD B2C) | |
| Web app that signs in users | Authorization code | Work or school accounts, personal accounts, and Azure AD B2C | |
| Web app that calls web APIs | Authorization code | Work or school accounts, personal accounts, and Azure AD B2C | |
| Desktop app that calls web APIs | Interactive by using authorization code with PKCE | Work or school accounts, personal accounts, and Azure AD B2C | |
| Integrated Windows authentication | Work or school accounts | ||
| Resource owner password | Work or school accounts and Azure AD B2C | ||
| Device code | Work or school accounts, personal accounts, but not Azure AD B2C | ||
| Mobile app that calls web APIs | Interactive by using authorization code with PKCE | Work or school accounts, personal accounts, and Azure AD B2C | |
| Resource owner password | Work or school accounts and Azure AD B2C | ||
| Daemon app that calls web APIs | Client credentials | App-only permissions that have no user and are used only in Microsoft Entra organizations | |
| Web API that calls web APIs | On-behalf-of | Work or school accounts and personal accounts |
Recap:
Azure App Service provides robust authentication solutions for web apps and APIs, offering a range of options to suit different scenarios.
Authentication Solutions:
- Azure App Service Built-in Authentication: Ideal for scenarios requiring minimal coding, supporting various languages and libraries without the need for security expertise. It’s particularly useful for legacy app migration and external user sign-ins.
- Microsoft Authentication Library (MSAL): A versatile library for acquiring security tokens, supporting multiple platforms and languages. It’s suitable for adding custom authorization logic, handling token expiration seamlessly, and integrating with various sign-in providers.
- Microsoft.Identity.Web: A higher-level library designed for ASP.NET Core applications, providing a streamlined API that integrates with MSAL.NET and other Microsoft services. It simplifies the authentication process and is recommended for apps requiring single sign-on, custom authorization, and advanced features like conditional access.
Best Practices:
- Assign unique app registrations and permissions for each App Service app.
- Use separate app registrations for different deployment slots to avoid permission sharing and potential production issues.
Application Categorization:
- Modern Authentication Apps: Utilize modern protocols like OIDC, OAuth2, SAML, or federation services.
- Web Access Management (WAM) Tools: Employ headers, cookies, and similar techniques for SSO, typically requiring a WAM identity provider.
- Legacy Apps: Rely on legacy protocols, which are not recommended due to security concerns.
Authentication Protocols:
- OpenID Connect (OIDC): An identity layer on top of OAuth2, enabling SSO with an ID token.
- OAuth2: An authorization framework for accessing user accounts on HTTP services.
- SAML: An XML-based standard for exchanging authentication and authorization data.
- WS-Federation: A protocol for federating security realms using tokens.
Key Differences:
- OpenID Connect vs. OAuth: OIDC focuses on user authentication, while OAuth is about resource access delegation.
- ADAL vs. MSAL: ADAL is deprecated and supports Azure AD v1.0 endpoint, while MSAL is the recommended library supporting Azure AD v2.0 and B2C endpoints with advanced features.
Application Types and Authentication Flows:
- Single-Page Applications (SPAs): Acquire tokens via JavaScript or TypeScript in the browser.
- Public Client Applications: Sign in users for desktop, mobile, and IoT devices.
- Confidential Client Applications: Include web apps and web APIs that call other web APIs, as well as daemon apps.
Conclusion
In summary, Azure App Service’s authentication capabilities are comprehensive, catering to a wide array of application types and architectural needs. By following best practices and selecting the appropriate authentication method, developers can secure their applications effectively while leveraging the full power of the Microsoft identity platform.
Conclusion: Authentication in Azure App Service
In summary, Azure App Service’s authentication capabilities are comprehensive, catering to a wide array of application types and architectural needs.
By following best practices and selecting the appropriate authentication method, developers can secure their applications effectively while leveraging the full power of the Microsoft identity platform.
We explored Azure App Service’s authentication options, best practices, application categorization, key protocol differences, and application types. It provides a clear and concise overview suitable for understanding the various aspects of authentication within the Azure App Service ecosystem.
References:
https://learn.microsoft.com/en-us/azure/app-service/identity-scenarios
https://learn.microsoft.com/en-us/entra/identity-platform/authentication-flows-app-scenarios