This chapter covers Azure App Service Authentication (Easy Auth), a built-in feature that simplifies adding authentication to your web apps, mobile backends, and API apps. On the AZ-204 exam, this topic appears in roughly 5-10% of questions, primarily under objective 3.1 (Implement authentication and authorization). Understanding Easy Auth is critical because it allows you to secure your applications with minimal code, integrate with multiple identity providers, and offload token validation and session management to the platform. We'll dive deep into how it works, configuration options, common pitfalls, and exactly what the exam expects you to know.
Jump to a section
Think of App Service Authentication (Easy Auth) as a hotel's key card access system for its guests. When a guest arrives at the hotel (user makes a request to your app), they first encounter the front desk (Easy Auth middleware) before they can go to their room (your app code). The front desk checks if the guest has a valid key card (authentication token). If not, they are directed to the registration desk (identity provider like Azure AD, Facebook, Google) to get one. The registration desk verifies the guest's identity (e.g., passport, driver's license) and issues a key card (token) that contains their room number and stay dates (claims). The guest then returns to the front desk, presents the key card, and the front desk validates the card by checking the magnetic stripe (token signature and expiration) against the hotel's master system (token validation with issuer). Once validated, the front desk records the guest's arrival (injects user claims into request headers) and allows them to proceed to their room (forwards request to your app). Importantly, the front desk does not need to know every guest personally—it just trusts the registration desk's issued card. This is exactly how Easy Auth works: it intercepts requests, handles authentication with external identity providers, validates tokens, and passes user information to your app via headers, without your app needing to write any authentication code.
What is App Service Authentication (Easy Auth)?
App Service Authentication, commonly referred to as Easy Auth, is a feature of Azure App Service (including Web Apps, Mobile Apps, API Apps, and Function Apps) that provides built-in authentication and authorization support with minimal code. Instead of implementing OAuth 2.0 flows, token validation, and session management yourself, you can enable Easy Auth with a few clicks in the Azure portal or via CLI/ARM templates. It acts as a middleware layer that sits in front of your application, intercepting incoming HTTP requests and handling authentication before the request reaches your app code.
Why Does Easy Auth Exist?
Building secure authentication from scratch is complex and error-prone. Developers must handle:
Redirecting users to identity providers (IdPs) like Azure AD, Facebook, Google, Microsoft Account, Twitter, or Apple.
Exchanging authorization codes for tokens.
Validating JWT tokens (signature, issuer, audience, expiration).
Managing session state (cookies or tokens).
Refreshing tokens when they expire.
Handling logout and token revocation.
Easy Auth abstracts all of this. It runs as a native IIS module (on Windows) or as a sidecar container (on Linux) that processes requests before they reach your application. It can be configured to authenticate users with one or more identity providers, and it injects user claims into HTTP headers that your backend code can read. This means you can focus on your application logic while Azure handles the security plumbing.
How Easy Auth Works Internally
The authentication flow in Easy Auth follows a standard OAuth 2.0 authorization code flow with PKCE (Proof Key for Code Exchange) for enhanced security. Here is a step-by-step breakdown of the mechanism:
User makes a request to your app – The user's browser sends an HTTP request to your App Service endpoint (e.g., https://myapp.azurewebsites.net).
Easy Auth intercepts the request – The App Service platform examines the request for authentication tokens. It checks for:
- A session token cookie (issued by Easy Auth after successful authentication)
- An Authorization header with a Bearer token (for API calls)
- An identity provider token (e.g., Facebook access token) passed via a header or query parameter (if configured)
3. If the request is not authenticated – The platform returns a 302 redirect to the identity provider's authorization endpoint (e.g., Azure AD's /oauth2/v2.0/authorize). The redirect URL includes necessary parameters like client_id, redirect_uri, response_type=code, and scope. The redirect_uri points back to /.auth/login/<provider>/callback.
4. User authenticates with the IdP – The user logs in at the identity provider (e.g., enters credentials, consents to permissions). The IdP then redirects the user back to the callback URL with an authorization code.
5. Easy Auth exchanges the code for tokens – The platform's middleware receives the authorization code and makes a back-channel request to the IdP's token endpoint to exchange it for an ID token, access token, and optionally a refresh token. This exchange is done securely server-side.
6. Token validation – Easy Auth validates the ID token (JWT) by checking the signature against the IdP's public keys (fetched from the JWKS URI), verifying the issuer (iss claim), audience (aud claim), and expiration (exp claim). It also validates nonce to prevent replay attacks.
7. Session token issued – Upon successful validation, Easy Auth creates its own session token (a cookie) that is encrypted and stored on the client. This session token is used for subsequent requests to avoid re-authentication. The session cookie has a configurable expiration (default: 8 hours) and can be set to slide (renew on activity) or absolute.
8. User claims injected into headers – The platform extracts claims from the validated ID token and injects them into HTTP headers that are forwarded to your application. Key headers include:
- X-MS-CLIENT-PRINCIPAL-NAME – The user's name (e.g., UPN for Azure AD)
- X-MS-CLIENT-PRINCIPAL-ID – The user's unique identifier (e.g., object ID)
- X-MS-TOKEN-AAD-ID-TOKEN – The raw ID token (if needed)
- X-MS-TOKEN-AAD-ACCESS-TOKEN – The access token for calling downstream APIs
- X-MS-CLIENT-PRINCIPAL – A base64-encoded JSON object containing all claims
9. Request forwarded to your app – The original request, now with the injected headers, is passed to your application code. Your app can read these headers to identify the user and make authorization decisions.
Key Components, Values, Defaults, and Timers
- Authentication providers: Azure AD, Microsoft Account (MSA), Facebook, Google, Twitter, Apple, and any OpenID Connect provider.
- Session cookie name: AppServiceAuthSession (customizable via authCookieName).
- Session cookie expiration: Default 8 hours (configurable via tokenStore.tokenRefreshExtensionHours or globalValidation.sessionCookieExpirationTime).
- Token store: Easy Auth can store tokens in a shared file system (default) or an Azure Cache for Redis (for scaled-out scenarios). The token store is used to cache tokens and session data.
- Allowed token audiences: By default, the audience is the App Service's URL. For custom APIs, you can configure allowedAudiences.
- Redirect URL format: https://<app-name>.azurewebsites.net/.auth/login/<provider>/callback.
- Logout URL: https://<app-name>.azurewebsites.net/.auth/logout.
- Unauthenticated request action: Can be set to:
- RedirectToLoginPage (default) – Redirects to the IdP login.
- AllowAnonymous – Passes the request through without authentication.
- Return401 – Returns HTTP 401 Unauthorized.
- Return403 – Returns HTTP 403 Forbidden.
- Token refresh: Easy Auth can automatically refresh tokens using refresh tokens if the provider returns them. The tokenRefreshExtensionHours setting (default 72 hours) controls how long before token expiry the refresh is attempted.
Configuration and Verification Commands
You can configure Easy Auth via the Azure portal, Azure CLI, Azure PowerShell, or ARM templates. Here are common Azure CLI commands:
Enable Easy Auth with Azure AD as provider:
az webapp auth update --resource-group myResourceGroup --name myApp --enabled true --action LoginWithAzureActiveDirectory --aad-client-id <client-id> --aad-client-secret <client-secret> --aad-token-issuer-url https://login.microsoftonline.com/<tenant-id>/v2.0Set unauthenticated requests action to allow anonymous:
az webapp auth update --resource-group myResourceGroup --name myApp --enabled true --action AllowAnonymousConfigure token store with Redis:
az webapp auth update --resource-group myResourceGroup --name myApp --token-store-enabled true --token-store-redis-cache-connection-string <redis-connection-string>Verify current authentication settings:
az webapp auth show --resource-group myResourceGroup --name myAppCheck logs for authentication failures:
- In the Azure portal, navigate to your App Service -> Monitor -> Log stream.
- Look for logs from Microsoft.AspNetCore.Authentication or EasyAuthModule_32/64.
How Easy Auth Interacts with Related Technologies
Azure AD B2C: Easy Auth can be configured with Azure AD B2C as a custom OpenID Connect provider. This allows social identity logins (Facebook, Google) while using B2C's user management. Configuration involves setting the customOpenIdConnectProviders property with the B2C tenant's metadata endpoint.
Azure API Management (APIM): If your app is behind APIM, you can use Easy Auth on the App Service side, or you can use APIM's built-in OAuth 2.0 validation. A common pattern is to let APIM validate tokens and pass claims downstream, but you can also have Easy Auth do the validation if the app is directly exposed.
Azure Functions: Easy Auth works identically for Functions. You can enable it on a Function App to secure HTTP-triggered functions. The same headers are injected, and you can read them in your function code.
Azure Front Door / Application Gateway: When using a reverse proxy, the client IP and headers may be modified. Easy Auth relies on the original request context, so ensure that the proxy forwards the original host and protocol correctly (e.g., X-Forwarded-For, X-Forwarded-Proto).
Key Vault: Client secrets for identity providers can be stored in Azure Key Vault and referenced using a secret URI (e.g., @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)). This avoids hardcoding secrets in configuration.
Performance and Scale Considerations
Easy Auth adds minimal latency (a few milliseconds) because it runs in the same process (Windows) or as a sidecar (Linux).
For high-traffic apps, consider using a Redis cache for the token store to avoid file system contention across multiple instances.
The session cookie size is small (typically < 4 KB), but if you store many claims, it can grow. Claims are stored in the token store, not in the cookie itself; the cookie is just a reference.
Easy Auth does not support custom claims mapping or transformation. If you need to add custom claims, you must do so in your application code after authentication.
Limitations and Edge Cases
Easy Auth does not support custom login pages. The user is always redirected to the IdP's login page.
It does not support multi-factor authentication (MFA) policies beyond what the IdP enforces. For example, Azure AD Conditional Access policies (including MFA) are still enforced by Azure AD, but Easy Auth passes through the resulting tokens.
Easy Auth cannot be used to authenticate users for WebSocket connections directly. You need to handle authentication in your WebSocket handler.
The /.auth/* endpoints are internal and not meant for custom use. However, you can use /.auth/me to get the current user's claims in JSON format.
Easy Auth does not support logout from the identity provider (single sign-out). When you call /.auth/logout, it only clears the session cookie, not the IdP session.
Enable Easy Auth in App Service
In the Azure portal, navigate to your App Service and select 'Authentication' under Settings. Click 'Add identity provider' and choose a provider (e.g., Microsoft). You'll need to provide the Application (client) ID and a client secret from the Azure AD app registration. Optionally, set the issuer URL and allowed token audiences. After saving, Easy Auth is enabled and will intercept all incoming requests. The platform automatically creates the necessary redirect URIs (e.g., `/.auth/login/aad/callback`) in the App Service's authentication settings, but you must also register these redirect URIs in the identity provider's app registration manually.
User attempts to access the app
The user's browser sends an HTTP GET request to `https://myapp.azurewebsites.net`. The App Service front-end (the Easy Auth module) intercepts the request before it reaches your application code. It checks for the presence of a valid authentication token. This check is done by looking for the `AppServiceAuthSession` cookie (for browser requests) or an `Authorization: Bearer <token>` header (for API requests). If no token is found, the module determines the action based on the 'Unauthenticated requests' setting. The default is `RedirectToLoginPage`, so the user receives an HTTP 302 redirect.
Redirect to identity provider login
The 302 redirect URL points to the identity provider's authorization endpoint. For Azure AD, the URL is something like `https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize?client_id=<client-id>&response_type=code&redirect_uri=https://myapp.azurewebsites.net/.auth/login/aad/callback&scope=openid+profile+email&state=<generated-state>`. The `state` parameter is a nonce to prevent CSRF attacks. The user's browser follows this redirect, and the user is presented with the Azure AD login page. If the user is already signed in to Azure AD (e.g., via SSO), they may be silently redirected back without interaction.
User authenticates and receives authorization code
The user enters their credentials (and possibly performs MFA if required by Conditional Access). Azure AD validates the credentials and, upon success, redirects the user back to the callback URL with an authorization code: `https://myapp.azurewebsites.net/.auth/login/aad/callback?code=<authorization_code>&state=<state>&session_state=<session_state>`. The Easy Auth module receives this request at the callback endpoint. It first validates the `state` parameter to ensure it matches the one sent earlier. Then, it extracts the authorization code.
Exchange code for tokens and validate
The Easy Auth module makes a server-to-server POST request to the identity provider's token endpoint (e.g., `https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token`) with the authorization code, client ID, client secret, and redirect URI. The identity provider responds with an ID token, access token, and optionally a refresh token. Easy Auth validates the ID token by checking the signature using the IdP's public keys (fetched from `https://login.microsoftonline.com/<tenant-id>/discovery/v2.0/keys`), verifying the issuer, audience, and expiration. It also validates the nonce claim if present. If all checks pass, Easy Auth creates an encrypted session cookie containing a reference to the user's principal and tokens, which are stored in the token store (file system or Redis). The cookie is set on the user's browser.
User claims injected and request forwarded to app
After successful authentication, the original request (or the callback redirect) is modified to include user claims in HTTP headers. The Easy Auth module adds headers like `X-MS-CLIENT-PRINCIPAL-NAME`, `X-MS-CLIENT-PRINCIPAL-ID`, and `X-MS-TOKEN-AAD-ID-TOKEN`. The request is then forwarded to your application code. Your app can read these headers to identify the user. For example, in a .NET Core app, you can access `HttpContext.Request.Headers["X-MS-CLIENT-PRINCIPAL-NAME"]`. The session cookie is also set so that subsequent requests are automatically authenticated without redirecting the user again.
Enterprise Scenario 1: Internal Enterprise Web Application with Azure AD
A large corporation deploys an internal expense reporting web app on Azure App Service. They enable Easy Auth with Azure AD as the sole identity provider. The app is registered in Azure AD with the appropriate redirect URIs. Conditional Access policies enforce MFA for all users accessing the app. Easy Auth handles the authentication flow, including MFA challenges, because Azure AD issues tokens only after MFA is satisfied. The app itself never sees the MFA challenge—it only receives authenticated requests. The development team saves weeks of effort by not implementing OAuth flows. In production, the app runs across multiple instances behind a load balancer. The token store is configured to use Azure Cache for Redis to ensure session persistence across instances. Performance is excellent, with Easy Auth adding under 10ms overhead. Common issues include misconfigured redirect URIs (e.g., not including the trailing slash) and expired client secrets. Monitoring is done via Application Insights, which logs authentication failures from Easy Auth as HTTP 401/403 responses.
Enterprise Scenario 2: Multi-Tenant SaaS Application with Social Identity Providers
A SaaS startup builds a customer portal that allows users to sign in with Google or Facebook. They use Easy Auth with custom OpenID Connect providers to integrate with Azure AD B2C, which in turn federates with Google and Facebook. The app is multi-tenant, so each customer has their own B2C tenant. Easy Auth's allowedAudiences setting is configured to accept tokens from multiple B2C tenants. The app uses the X-MS-TOKEN-AAD-ACCESS-TOKEN header to call downstream APIs (e.g., Graph API) on behalf of the user. The token refresh feature is enabled so that long-running operations can use refreshed access tokens. One pitfall: Easy Auth's token store does not automatically refresh tokens for the app to use; the app must use the refresh token from the X-MS-TOKEN-AAD-REFRESH-TOKEN header (if available) to obtain new tokens. The team learned this the hard way when their API calls started failing after 1 hour. They now use the Microsoft Authentication Library (MSAL) to handle token refresh explicitly, but they still rely on Easy Auth for initial authentication and session management.
Enterprise Scenario 3: Public API secured with Easy Auth
A company exposes a public REST API using Azure Functions with Easy Auth enabled. They require all requests to include a valid Azure AD access token in the Authorization header. Easy Auth validates the token and injects claims into headers. The function code reads the X-MS-CLIENT-PRINCIPAL-ID header to identify the caller and authorize access to resources. The unauthenticated requests action is set to Return401 to avoid redirecting API clients. The token validation includes audience checking: only tokens issued for the Function App's URL are accepted. However, the API also needs to be called by a daemon service using client credentials flow. Easy Auth supports this because Azure AD issues tokens with the same audience. The daemon's token is validated just like a user token, but the X-MS-CLIENT-PRINCIPAL-ID header will contain the service principal's object ID. One common mistake is forgetting to set the allowedAudiences when the API is behind a custom domain—tokens must be issued for that custom domain, not the default azurewebsites.net domain.
What AZ-204 Specifically Tests (Objective 3.1)
The exam focuses on your ability to implement authentication for App Service and Azure Functions using Easy Auth. You must know:
How to enable Easy Auth for different identity providers (Azure AD, Microsoft, Facebook, Google, Twitter, Apple, OpenID Connect).
The authentication flow (redirect, callback, token exchange, session cookie).
The HTTP headers injected for user claims (X-MS-CLIENT-PRINCIPAL-NAME, X-MS-CLIENT-PRINCIPAL-ID, X-MS-CLIENT-PRINCIPAL, X-MS-TOKEN-*).
How to configure unauthenticated request behavior (RedirectToLoginPage, AllowAnonymous, Return401, Return403).
How to use token store with Redis for scaling.
How to integrate with Azure AD B2C as a custom provider.
The difference between Easy Auth and implementing authentication with MSAL (Easy Auth handles the OAuth flow for you; MSAL gives you more control).
Common Wrong Answers and Why Candidates Choose Them
'Easy Auth stores user claims in the session cookie' – WRONG. The session cookie is just an encrypted reference; claims are stored in the token store (file or Redis). Candidates assume that because the cookie is small, claims must be in it. But the cookie only contains a session ID; the actual token and claims are stored server-side.
'Easy Auth automatically refreshes tokens for downstream API calls' – WRONG. Easy Auth can store refresh tokens, but it does not automatically refresh them for the app. The app must use the refresh token from the header to obtain new access tokens. Many candidates think the platform handles everything.
'You must set the redirect URI to your app's root URL' – WRONG. The redirect URI must be https://<app>.azurewebsites.net/.auth/login/<provider>/callback. Candidates often forget the /.auth/login/... path.
'Easy Auth supports custom login pages' – WRONG. Easy Auth always redirects to the IdP's login page. If you need a custom UI, you must implement authentication yourself (e.g., with MSAL).
Specific Numbers, Values, and Terms
Session cookie name: AppServiceAuthSession
Default session cookie expiration: 8 hours
Token refresh extension: 72 hours (default)
Unauthenticated request actions: RedirectToLoginPage, AllowAnonymous, Return401, Return403
Header names: X-MS-CLIENT-PRINCIPAL-NAME, X-MS-CLIENT-PRINCIPAL-ID, X-MS-CLIENT-PRINCIPAL, X-MS-TOKEN-<PROVIDER>-<TOKEN-TYPE>
Callback endpoint: /.auth/login/<provider>/callback
Logout endpoint: /.auth/logout
Token store: file system (default) or Azure Cache for Redis
Edge Cases and Exceptions
When using a custom domain, you must set the allowedAudiences to include the custom domain URL; otherwise, token validation fails because the audience (the app's URL) doesn't match.
If you enable Easy Auth but set unauthenticated requests to AllowAnonymous, the app receives requests with or without authentication. The headers are still injected if a token is present, but anonymous requests have empty headers. Your code must handle the case where headers are missing.
Easy Auth does not work with WebSocket connections out of the box. You need to authenticate WebSocket connections separately.
For Azure Functions, Easy Auth works only for HTTP triggers. Other trigger types (e.g., Service Bus, Blob) are not affected.
How to Eliminate Wrong Answers
If a question asks about retrieving user identity in an App Service with Easy Auth, look for answers that mention reading X-MS-CLIENT-PRINCIPAL-NAME header. Eliminate answers that suggest reading HttpContext.User – Easy Auth does not populate that; it only sets headers. Also, if the question involves scaling, think about Redis for token store. If it's about custom authentication UI, Easy Auth is not the answer. Use the mechanism (middleware intercepts, redirects, injects headers) to reason through the options.
Easy Auth is a middleware that intercepts requests before they reach your app, handling authentication with external identity providers.
The session cookie is named `AppServiceAuthSession` and has a default expiration of 8 hours (configurable).
User claims are injected into HTTP headers like `X-MS-CLIENT-PRINCIPAL-NAME` and `X-MS-CLIENT-PRINCIPAL-ID`.
Unauthenticated request actions: RedirectToLoginPage (default), AllowAnonymous, Return401, Return403.
For scaled-out apps, use Azure Cache for Redis as the token store to ensure session persistence.
Easy Auth does not automatically refresh tokens for downstream APIs; your app must use refresh tokens from headers.
The callback URL format is `/.auth/login/<provider>/callback` – must be registered in the identity provider.
Easy Auth supports Azure AD, Microsoft Account, Facebook, Google, Twitter, Apple, and any OpenID Connect provider.
These come up on the exam all the time. Here's how to tell them apart.
Easy Auth (App Service Authentication)
Minimal code – no OAuth flow implementation needed.
Handles token validation, session management, and token storage automatically.
Injects user claims into HTTP headers; does not populate HttpContext.User.
Limited customization – cannot customize login page or claims transformation.
Best for simple scenarios or when you want to offload authentication to the platform.
Custom Authentication with MSAL
Full control over authentication flow, UI, and claims.
Requires implementing OAuth 2.0 flow, token validation, and session management in code.
Populates HttpContext.User directly (in ASP.NET Core) via middleware.
Supports custom login pages, MFA policies, and claims augmentation.
Best for complex scenarios requiring custom branding, multiple IdPs, or fine-grained control.
Mistake
Easy Auth stores all user claims in the session cookie.
Correct
The session cookie is an encrypted reference (session ID) that points to the actual token and claims stored in the token store (file system or Redis). The cookie itself is small and does not contain claims.
Mistake
Easy Auth automatically refreshes tokens for calling downstream APIs.
Correct
Easy Auth stores refresh tokens but does not automatically use them to refresh access tokens for your application. Your code must use the refresh token from the header (e.g., `X-MS-TOKEN-AAD-REFRESH-TOKEN`) to obtain new tokens via MSAL or direct HTTP calls.
Mistake
You can use Easy Auth with a custom login page that you design.
Correct
Easy Auth always redirects users to the identity provider's login page. It does not support custom login pages. If you need a custom UI, you must implement authentication using MSAL or another library.
Mistake
Easy Auth populates HttpContext.User with the authenticated user principal.
Correct
Easy Auth injects user claims into HTTP headers only. It does not set `HttpContext.User`. Your application code must read the headers (e.g., `X-MS-CLIENT-PRINCIPAL-NAME`) to identify the user. Some frameworks can be configured to map these headers to the principal, but it is not automatic.
Mistake
Easy Auth supports all OAuth 2.0 flows, including client credentials for daemon apps.
Correct
Easy Auth primarily supports the authorization code flow with PKCE for interactive users. It can validate tokens from the client credentials flow if the token is passed in the `Authorization` header, but it does not initiate the client credentials flow itself. Daemon apps must obtain tokens separately and include them in requests.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Read the `X-MS-CLIENT-PRINCIPAL-NAME` HTTP header from the incoming request. For example, in an ASP.NET Core controller, use `Request.Headers["X-MS-CLIENT-PRINCIPAL-NAME"]`. In Azure Functions, access it via `req.Headers`. This header contains the user's display name or UPN. Do not rely on `HttpContext.User` because Easy Auth does not set it automatically. If you need all claims, read the `X-MS-CLIENT-PRINCIPAL` header, which is a base64-encoded JSON object containing the full principal.
Yes. When you configure a custom domain for your App Service, you must update the identity provider's redirect URIs to use the custom domain (e.g., `https://app.contoso.com/.auth/login/aad/callback`). Additionally, set the `allowedAudiences` in Easy Auth configuration to include the custom domain URL (e.g., `https://app.contoso.com`). Otherwise, token validation will fail because the token's audience (`aud` claim) will not match the App Service's URL. Also ensure that your custom domain has a valid SSL certificate.
When the session cookie expires, the user is treated as unauthenticated on the next request. Easy Auth will redirect them to the identity provider for re-authentication (if unauthenticated action is set to RedirectToLoginPage). The user may be automatically signed in again if they have an active session with the IdP (e.g., still logged into Azure AD). You can configure the session cookie expiration time and whether it slides (renews on activity) or is absolute. The default is a sliding expiration of 8 hours.
Yes, Easy Auth works identically for Azure Functions as it does for Web Apps. You can enable it in the Function App's Authentication settings. It intercepts HTTP trigger requests and injects the same headers. Non-HTTP triggers (e.g., Service Bus, Blob, Cosmos DB) are not affected. For HTTP triggers, you can read user claims from headers. Note that Easy Auth does not support Functions running in the Consumption plan with certain runtime versions? Actually, it is supported on all plans, but be aware of cold start implications: the authentication middleware adds a small overhead.
Azure AD B2C is not listed as a built-in provider. You must configure it as a custom OpenID Connect provider. In the Azure portal, go to Authentication -> Add identity provider -> OpenID Connect. Provide a name, the metadata URL (e.g., `https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=<policy-name>`), client ID, client secret, and the scopes (e.g., `openid`). Also set the allowed token audiences to the B2C application ID. The callback URL will be `/.auth/login/<provider-name>/callback` and must be registered in the B2C app registration.
No, Easy Auth applies globally to all routes in your App Service or Function App. It intercepts every incoming HTTP request. If you need to allow anonymous access to certain paths (e.g., a health check endpoint), you can handle that in your application code by checking for the presence of the `X-MS-CLIENT-PRINCIPAL-ID` header. Alternatively, you can set the unauthenticated requests action to `AllowAnonymous` and then enforce authentication in your code for specific routes using standard authorization attributes.
They are the same thing. 'Easy Auth' is the informal name for App Service's built-in authentication feature. The official term in documentation is 'Authentication and authorization in Azure App Service' or 'App Service Authentication'. It is a feature that provides an authentication layer without requiring code changes. It is distinct from implementing authentication using libraries like MSAL, which gives you more control but requires more code.
You've just covered App Service Authentication (Easy Auth) — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?