App Service Security and Authentication

Azure App Service is a fully managed platform for building and hosting web apps, REST APIs, and mobile back ends. Security in App Service involves multiple layers: authentication (verifying user identity), authorization (controlling access to resources), network security (restricting inbound/outbound traffic), and data protection (encryption at rest and in transit). The AZ-500 exam specifically tests your ability to configure and manage these security features, especially the built-in authentication and authorization module, often referred to as EasyAuth.

Traditionally, developers had to implement authentication logic themselves using SDKs or middleware, which is error-prone and time-consuming. EasyAuth provides a turnkey solution that runs as a native IIS module or sidecar container (on Linux) in front of your application. It intercepts incoming HTTP requests before they reach your app code, validates tokens, and either allows the request, challenges the client, or injects identity headers. This means your app never directly handles tokens or passwords—reducing attack surface.

When you enable authentication in App Service, you select one or more identity providers (Azure AD, Microsoft Account, Facebook, Google, Twitter, or any OpenID Connect provider). The App Service front-end layer (Front End or Azure Front Door) handles token validation. Here's the step-by-step mechanism:

You can configure authentication via Azure portal, Azure CLI, or ARM templates. Example Azure CLI:

# Enable Azure AD authentication
az webapp auth update --resource-group myRG --name myApp --enabled true \
  --action LoginWithAzureActiveDirectory \
  --aad-client-id <client-id> --aad-client-secret <secret> --aad-token-store true

# Show current auth settings
az webapp auth show --resource-group myRG --name myApp

# Get token from /.auth/me
curl -X GET https://myapp.azurewebsites.net/.auth/me -H "Cookie: AppServiceAuthSession=<cookie>"

Managed identity is a key feature for secure backend access. When enabled, Azure automatically creates a service principal in Azure AD for the App Service. Your code can acquire tokens for other Azure resources (like Key Vault, SQL Database, or Storage) without storing any credentials. Example C# code:

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

var client = new SecretClient(new Uri("https://myvault.vault.azure.net"), new DefaultAzureCredential());
KeyVaultSecret secret = await client.GetSecretAsync("mySecret");

The DefaultAzureCredential automatically uses the managed identity when running in App Service.

App Service supports TLS 1.2 and 1.3 by default. You can enforce minimum TLS version via portal or CLI:

az webapp config set --resource-group myRG --name myApp --min-tls-version 1.2

HTTPS Only can be enforced to redirect HTTP to HTTPS. Also, you can use App Service certificates, upload your own, or use Azure Key Vault for SSL binding.

CORS allows your API to be called from a different domain. Configure allowed origins in App Service. This is not a security feature per se but can be misused if overly permissive. Best practice: allow only specific domains.

You can enable multiple providers. Users choose which one to log in with. The token store stores tokens from each provider. The /.auth/me endpoint returns claims from the provider used to authenticate.

A company develops a web app for employee expense reporting. They need to restrict access to employees only and ensure that the app can read user profile data from Azure AD. They enable Azure AD authentication in App Service with 'Login with Azure Active Directory' and 'Allow unauthenticated requests' set to redirect. They register an app in Azure AD with User.Read permission. They also enable system-assigned managed identity so that the app can access a backend SQL database using Azure AD authentication. The app uses the managed identity token to connect to the database without storing any credentials. To further secure the app, they enforce HTTPS only and TLS 1.2. They also configure Access Restrictions to allow traffic only from the corporate office IP range and the company VPN. This setup ensures that only authenticated employees from trusted networks can access the application, and backend connections are secure.

A SaaS provider hosts a customer-facing portal on App Service. They use Azure AD B2C for customer identity management. They configure multiple identity providers (local accounts, Google, Facebook) in B2C and integrate with App Service using OpenID Connect. The App Service authentication module is set to 'Allow anonymous requests' because the app handles routing to different B2C policies based on the URL. The app uses the /.auth/me endpoint to retrieve claims. They also use user-assigned managed identity for each tenant's backend storage account to ensure isolation. Performance considerations: token validation adds latency, so they cache tokens in memory. They also use Azure Front Door for global load balancing and DDoS protection. A common misconfiguration here is not setting the correct redirect URIs in B2C, causing login failures.