Azure App Service provides built-in authentication (signing in users) and authorization (providing access to secure data) capabilities. These capabilities are sometimes called Easy Auth. You can use them to sign in users and access data by writing little or no code in your web app, RESTful API, mobile server, and functions.
This article describes how App Service helps simplify authentication and authorization for your app.
Reasons to use built-in authenticationTo implement authentication and authorization, you can use the bundled security features in your web framework of choice, or you can write your own tools. Implementing a secure solution for authentication and authorization can take significant effort. You need to follow industry best practices and standards. You also need to ensure that your solution stays up to date with the latest security, protocol, and browser updates.
The built-in capabilities of App Service and Azure Functions can save you time and effort by providing out-of-the-box authentication with federated identity providers, so you can focus on the rest of your application.
With App Service, you can integrate authentication capabilities into your web app or API without implementing them yourself. This feature is built directly into the platform and doesn't require any particular language, SDK, security expertise, or code. You can integrate it with multiple sign-in providers, such as Microsoft Entra, Facebook, Google, and X.
Your app might need to support more complex scenarios, such as Visual Studio integration or incremental consent. Several authentication solutions are available to support these scenarios. To learn more, see Authentication scenarios and recommendations.
Identity providersApp Service uses federated identity. A Microsoft or non-Microsoft identity provider manages the user identities and authentication flow for you. The following identity providers are available by default:
When you configure this feature with one of these providers, its sign-in endpoint is available for user authentication and for validation of authentication tokens from the provider. You can provide your users with any number of these sign-in options.
Considerations for using built-in authenticationEnabling built-in authentication causesâ¯all requests to your application to be automatically redirected to HTTPS, regardless of the App Service configuration setting to enforce HTTPS. You can disable this automatic redirection by using the requireHttps setting in the V2 configuration. However, we recommend that you keep using HTTPS and ensure that no security tokens are ever transmitted over nonsecure HTTP connections.
You can use App Service for authentication with or without restricting access to your site content and APIs. Set access restrictions in the Settings > Authentication > Authentication settings section of your web app:
Important
You should give each app registration its own permission 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 problems from affecting the production app.
How it works Feature architectureThe authentication and authorization middleware component is a feature of the platform that runs on the same virtual machine as your application. When you enable it, every incoming HTTP request passes through that component before your application handles it.
The platform middleware handles several things for your app:
The module runs separately from your application code. You can configure it by using Azure Resource Manager settings or by using a configuration file. No SDKs, specific programming languages, or changes to your application code are required.
Feature architecture on Windows (non-container deployment)The authentication and authorization module runs as a native IIS module in the same sandbox as your application. When you enable it, every incoming HTTP request passes through it before your application handles it.
Feature architecture on Linux and containersThe authentication and authorization module runs in a separate container that's isolated from your application code. The module uses the Ambassador pattern to interact with the incoming traffic to perform similar functionality as on Windows. Because it doesn't run in process, no direct integration with specific language frameworks is possible. However, the relevant information that your app needs is passed through in request headers.
Authentication flowThe authentication flow is the same for all providers. It differs depending on whether you want to sign in with the provider's SDK:
Without provider SDK: The application delegates federated sign-in to App Service. This delegation is typically the case with browser apps, which can present the provider's sign-in page to the user. The server code manages the sign-in process, so it's also called server-directed flow or server flow.
This case applies to browser apps and mobile apps that use an embedded browser for authentication.
With provider SDK: The application signs in users to the provider manually. Then it submits the authentication token to App Service for validation. This process is typically the case with browserless apps, which can't present the provider's sign-in page to the user. The application code manages the sign-in process, so it's also called client-directed flow or client flow.
This case applies to REST APIs, Azure Functions, and JavaScript browser clients, in addition to browser apps that need more flexibility in the sign-in process. It also applies to native mobile apps that sign in users by using the provider's SDK.
Calls from a trusted browser app in App Service to another REST API in App Service or Azure Functions can be authenticated through the server-directed flow. For more information, see Customize sign-in and sign-out in Azure App Service authentication.
The following table shows the steps of the authentication flow.
Step Without provider SDK With provider SDK 1. Sign in the user Provider redirects the client to
/.auth/login/<provider>. Client code signs in the user directly with the provider's SDK and receives an authentication token. For more information, see the provider's documentation. 2. Conduct post-authentication Provider redirects the client to /.auth/login/<provider>/callback. Client code posts the token from the provider to /.auth/login/<provider> for validation. 3. Establish an authenticated session App Service adds an authenticated cookie to the response. App Service returns its own authentication token to the client code. 4. Serve authenticated content Client includes an authentication cookie in subsequent requests (automatically handled by the browser). Client code presents the authentication token in the X-ZUMO-AUTH header.
For client browsers, App Service can automatically direct all unauthenticated users to /.auth/login/<provider>. You can also present users with one or more /.auth/login/<provider> links to sign in to your app by using their provider of choice.
In the Azure portal, you can configure App Service with various behaviors when an incoming request isn't authenticated. The following sections describe the options.
Important
By default, this feature provides only authentication, not authorization. Your application might still need to make authorization decisions, in addition to any checks that you configure here.
Restricted accessAllow unauthenticated requests: This option defers authorization of unauthenticated traffic to your application code. For authenticated requests, App Service also passes along authentication information in the HTTP headers.
This option provides more flexibility in handling anonymous requests. For example, it lets you present multiple sign-in providers to your users. However, you must write code.
Require authentication: This option rejects any unauthenticated traffic to your application. Specific action to take is specified in the Unauthenticated requests section later in this article.
With this option, you don't need to write any authentication code in your app. You can handle finer authorization, such as role-specific authorization, by inspecting the user's claims.
Caution
Restricting access in this way applies to all calls to your app, which may not be desirable for apps wanting a publicly available home page, as in many single-page applications. If exceptions are needed, you need to configure excluded paths in a configuration-file.
When you're using the Microsoft identity provider for users in your organization, the default behavior is that any user in your Microsoft Entra tenant can request a token for your application. You can configure the application in Microsoft Entra if you want to restrict access to your app to a defined set of users. App Service also offers some basic built-in authorization checks that can help with some validations. To learn more about authorization in Microsoft Entra, see Microsoft Entra authorization basics.
Unauthenticated requests/.auth/login/<provider> for the provider that you choose.HTTP 401 Unauthorized response if the anonymous request comes from a native mobile app. You can also configure the rejection to be HTTP 401 Unauthorized for all requests.HTTP 403 Forbidden for all requests.HTTP 404 Not found for all requests.App Service provides a built-in token store. A token store is a repository of tokens that are associated with the users of your web apps, APIs, or native mobile apps. When you enable authentication with any provider, this token store is immediately available to your app.
If your application code needs to access data from these providers on the user's behalf, you typically must write code to collect, store, and refresh these tokens in your application. Actions might include:
With the token store, you just retrieve the tokens when you need them and tell App Service to refresh them when they become invalid.
The ID tokens, access tokens, and refresh tokens are cached for the authenticated session. Only the associated user can access them.
If you don't need to work with tokens in your app, you can disable the token store on your app's Settings > Authentication page.
Logging and tracingIf you enable application logging, authentication and authorization traces appear directly in your log files. If you see an authentication error that you didn't expect, you can conveniently find all the details by looking in your existing application logs.
If you enable failed request tracing, you can see exactly what role the authentication and authorization module might play in a failed request. In the trace logs, look for references to a module named EasyAuthModule_32/64.
App Service authentication mitigates cross-site request forgery by inspecting client requests for the following conditions:
POST request that authenticated through a session cookie.User-Agent header.Origin or HTTP Referer header is missing or isn't in the configured list of approved external domains for redirection.Origin header is missing or isn't in the configured list of cross-origin resource sharing (CORS) origins.When a request fulfills all these conditions, App Service authentication automatically rejects it. You can work around this mitigation logic by adding your external domain to the redirect list in Settings > Authentication > Edit authentication settings > Allowed external redirect URLs.
Considerations for using Azure Front DoorWhen you're using Azure App Service with authentication behind Azure Front Door or other reverse proxies, consider the following actions.
Disable Azure Front Door cachingDisable Azure Front Door caching for the authentication workflow.
Use the Azure Front Door endpoint for redirectsApp Service is usually not accessible directly when it's exposed by Azure Front Door. You can prevent this behavior, for example, by exposing App Service by using Azure Private Link in Azure Front Door Premium. To prevent the authentication workflow from redirecting traffic back to App Service directly. For more information, see Redirect URI.
Ensure that App Service is using the right redirect URIIn some configurations, App Service uses its fully qualified domain name (FQDN) as the redirect URI, instead of the Azure Front Door FQDN. This configuration causes a problem when the client is redirected to App Service instead of Azure Front Door. To change it, set forwardProxy to Standard to make App Service respect the X-Forwarded-Host header that Azure Front Door set.
Other reverse proxies, like Azure Application Gateway or non-Microsoft products, might use different headers and need a different forwardProxy setting.
You can't change the forwardProxy configuration by using the Azure portal. You need to use az rest.
az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json
Search for:
"httpSettings": {
"forwardProxy": {
"convention": "Standard"
}
}
Ensure that convention is set to Standard to respect the X-Forwarded-Host header that Azure Front Door uses.
az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json
For more information about App Service authentication, see:
For samples, see:
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4