/
Azure App Service

Azure App Service

Owned by Roger Cruz
Last updated: Feb 27, 2022

 

Expand all   Collapse all

Intro

Publishing a web app service

 

Documentation

 

Tips and Tidbits

  • A Web App is a web application that is hosted in an App Service.

  • The App Service is the managed service in Azure that enables you to deploy a web application and make it available to your customers on the Internet in a very short amount of time.

  • Azure App Service is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends

  • You can develop in your favorite language, be it .NET, .NET Core, Java, Ruby, Node.js, PHP, or Python.

  • Applications run and scale with ease on both Windows and Linux-based environments.

  • Global scale with high availability - Scale up or out manually or automatically.

    • Host your apps anywhere in Microsoft's global datacenter infrastructure, and the App Service SLA promises high availability.

  • You can deploy your application to App Service as code or as a ready-to-run Docker image. 

  • Out-of-the-box continuous integration and deployment with Azure DevOps, GitHub, Bitbucket, FTP, or a local Git repository on your development machine.

    • Connect your web app with any of the above sources and App Service will do the rest for you by auto-syncing code and any future changes on the code into the web app

  • Depending on the usage of the web app, you can scale your app up/down by increasing/decreasing the resources of the underlying machine that is hosting your web app

    • Resources can be number of cores or the amount of RAM available.

  • Scaling out is the ability to increase the number of machine instances that are running your web app.

    • In the Free and Shared tiers, an app receives CPU minutes on a shared VM instance and cannot scale out.

  • WebJobs is a feature of Azure App Service that enables you to run a program or script in the same instance as a web app, API app, or mobile app. There is no additional cost to use WebJobs.

  • Websites unload if they sit idle for too long, which helps the system conserve resources. The new Always On setting (available for Standard tier websites) keeps your site up and running, which translates to higher availability and faster response times across the board.

  • App Service on Linux supports a number of language specific built-in images.

    •  

Deploy to App Service

  • Deploy to App Service

  • Azure supports automated deployment directly from:

    • Azure DevOps, GitHub, Bitbucket

  • Manual deployment via:

    • Git: App Service web apps feature a Git URL that you can add as a remote repository. Pushing to the remote repository will deploy your app.

    • CLI: webapp up is a feature of the az command-line interface that packages your app and deploys it.

    • Zip deploy: Use curl or a similar HTTP utility to send a ZIP of your application files to App Service.

    • FTP/S: FTP or FTPS is a traditional way of pushing your code to many hosting environments, including App Service.

 

 

Deployment Slots

  • Within a single Azure App Service web app, you can create multiple deployment slots.

  • Each slot is a separate instance of that web app, and it has a separate host name. You can deploy a different version of your web app into each slot.

  • Deployment slots are live apps with their own host names.

    • App content and configurations elements can be swapped between two deployment slots, including the production slot.

  • The traffic redirection is seamless, and no requests are dropped because of swap operations.

  • Deployment slots facilitate two common deployment patterns: blue/green and A/B testing.

    • Blue-green deployment involves deploying an update into a production environment that is separate from the live application.

      • After the deployment is validated, traffic routing is switched to the updated version.

    • A/B testing involves gradually routing some of the traffic to a staging site in order to test a new version of an app

  • Deployment slots are only available in the Standard, Premium or Isolated plan tiers

  • You can’t name a slot “Production”. It is reserved.

 

  • Examine slot swapping

  • Some configuration elements follow the content across a swap (not slot specific), whereas other configuration elements stay in the same slot after a swap (slot specific).

Settings that are swapped

Settings that aren't swapped

Settings that are swapped

Settings that aren't swapped

General settings, such as framework version, 32/64-bit, web sockets

Publishing endpoints

App settings (can be configured to stick to a slot)

Custom domain names

Connection strings (can be configured to stick to a slot)

Non-public certificates and TLS/SSL settings

Handler mappings

Scale settings

Public certificates

WebJobs schedulers

WebJobs content

IP restrictions

Hybrid connections *

Always On

Virtual network integration *

Diagnostic log settings

Service endpoints *

Cross-origin resource sharing (CORS)

Azure Content Delivery Network *

 

  • When auto swap is enabled from a slot into production, every time you push your code changes to that slot, App Service automatically swaps the app into production after it's warmed up in the source slot.

    • Auto swap isn't currently supported in web apps on Linux.

  • Go to your app's resource page and select the deployment slot you want to configure to auto swap.

    • The setting is on the Configuration > General settings page.

    • Set Auto swap enabled to On. Then select the desired target slot for Auto swap deployment slot, and select Save on the command bar.



  • Specify custom warm-up

  • Some apps might require custom warm-up actions before the swap.

    • The applicationInitialization configuration element in web.config lets you specify custom initialization actions.

    • The swap operation waits for this custom warm-up to finish before swapping with the target slot. 

    • Most common deployment slot swap failures and how to fix them has a good explanation on appInit.

      • AppInit module uses the list of URL paths specified inside web.config file and makes internal HTTP requests to each of those.

        • All these requests are within the web app process.

  • If AppInit is not enabled then swap process just makes an HTTP request to the root path of the webapp on each web worker and as long as it receives some HTTP response it considers the warmup complete.

  • You can also customize the warm-up behavior with one or both of the following app settings:

    • WEBSITE_SWAP_WARMUP_PING_PATH: The path to ping to warm up your site..

    • WEBSITE_SWAP_WARMUP_PING_STATUSES: Valid HTTP response codes for the warm-up operation.

  • IIS 8.0 Application Initialization

  • Documentation on the IIS element Application Initialization <applicationInitialization>

    • The <applicationInitialization> element specifies that web application initialization is performed proactively before a request is received.

    • An application can start up more quickly if initialization sequences such as initializing connections, priming in-memory caches, running queries, and compiling page code are performed before the HTTP request is received.

    • Application Initialization can start the initialization process automatically whenever an application is started.

    • Application initialization also enables you to enhance the user experience during initialization by redirecting a request to static pages, such as a placeholder or splash screen.

    • Once the site is loaded, it will stop mapping the managed request to the static page, and will start serving the dynamic content.

    • How to script warm up of CloudService instances in Azure? Shows how to create an API Controller for doing additional initialization.

    • A hack to warm up functions: Application Initialization with Azure Functions in a dedicated plan only

    • Another hack to run a PHP script as part of the applicationInitialization workflow. It can be used to clear a local cache, for example.

    • Sitecore WarmUp Azure for Outscaling

    • Another hack to warm up other services when the web app restarts: Warming up your WCF Service on an Azure Cloud Service

 

 

  • Route traffic in App Service

  • By default, all client requests to the app's production URL (http://<app_name>.azurewebsites.net) are routed to the production slot.

    • You can route a portion of the traffic to another slot.

    • This feature is useful if you need user feedback for a new update, but you're not ready to release it to production.

       

    • After a client is automatically routed to a specific slot, it's "pinned" to that slot for the life of that client session.

      • On the client browser, you can see which slot your session is pinned to by looking at the x-ms-routing-name cookie in your HTTP headers.

      • A request that's routed to the "staging" slot has the cookie x-ms-routing-name=staging.

      • A request that's routed to the production slot has the cookie x-ms-routing-name=self.



         

      • To let users opt out of your beta app, for example, you can put this link on your webpage:

         

        <a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>





  • An app ( Web Apps, API Apps, or Mobile Apps) runs in an App Service plan.

    • An App Service plan defines a set of compute resources for a web app to run.

    • One or more apps can be configured to run on the same computing resources (or in the same App Service plan).

    • Every App Service web app you create must be assigned to a single App Service plan that runs it.

  • When the app runs, it runs on all the VM instances configured in the App Service plan.

    • If multiple apps are in the same App Service plan, they all share the same VM instances.

    • If you have multiple deployment slots for an app, all deployment slots also run on the same VM instances. 

  • Deploy the app to the production slot

az webapp up --location eastus --name rogercruzapp --html

 

#!/bin/bash # Replace the following URL with a public GitHub repo URL gitrepo=https://github.com/Azure-Samples/php-docs-hello-world webappname=mywebapp$RANDOM # Create a resource group. az group create --location westeurope --name myResourceGroup # Create an App Service plan in STANDARD tier (minimum required by deployment slots). az appservice plan create --name $webappname --resource-group myResourceGroup --sku S1 # Create a web app. az webapp create --name $webappname --resource-group myResourceGroup \ --plan $webappname #Create a deployment slot with the name "staging". az webapp deployment slot create --name $webappname --resource-group myResourceGroup \ --slot staging # Deploy sample code to "staging" slot from GitHub. az webapp deployment source config --name $webappname --resource-group myResourceGroup \ --slot staging --repo-url $gitrepo --branch master --manual-integration # Copy the result of the following command into a browser to see the staging slot. echo http://$webappname-staging.azurewebsites.net # Swap the verified/warmed up staging slot into production. az webapp deployment slot swap --name $webappname --resource-group myResourceGroup \ --slot staging # Copy the result of the following command into a browser to see the web app in the production slot. echo http://$webappname.azurewebsites.net

 

zip -r webapp.zip . az webapp deployment source config-zip --name rogercruzapp --resource-group roger_r_cruz_rg_5276 --src webapp.zip --slot testing Getting scm site credentials for zip deployment Starting zip deployment. This operation can take a while to complete ... Deployment endpoint responded with status code 202 { "active": true, "author": "N/A", "author_email": "N/A", "complete": true, "deployer": "ZipDeploy", "end_time": "2022-01-17T08:30:07.6022963Z", "id": "bd84b0397b60458283948569321675af", "is_readonly": true, "is_temp": false, "last_success_end_time": "2022-01-17T08:30:07.6022963Z", "log_url": "https://rogercruzapp-testing.scm.azurewebsites.net/api/deployments/latest/log", "message": "Created via a push deployment", "progress": "", "provisioningState": "Succeeded", "received_time": "2022-01-17T08:29:53.792608Z", "site_name": "rogercruzapp", "start_time": "2022-01-17T08:29:54.0122247Z", "status": 4, "status_text": "", "url": "https://rogercruzapp-testing.scm.azurewebsites.net/api/deployments/latest" }

Networking

 

  • Discover App Service networking features

  • By default, apps hosted in App Service are accessible directly through the internet and can reach only internet-hosted endpoints.

  • But for many applications, you need to control the inbound and outbound network traffic.

  • There are two main deployment types for Azure App Service.

    • The multitenant public service hosts App Service plans in the Free, Shared, Basic, Standard, Premium, PremiumV2, and PremiumV3 pricing SKUs.

    • There is also the single-tenant App Service Environment (ASE) hosts Isolated SKU App Service plans directly in your Azure virtual network.

 

 

App Service has two variations:

  • The dedicated compute pricing tiers, which include the Basic, Standard, Premium, Premium v2, and Premium v3.

  • The App Service Environment (ASE), which deploys directly into your virtual network with dedicated supporting infrastructure and is using the Isolated and Isolated v2 pricing tiers.

  • The VNet integration feature is used in Azure App Service dedicated compute pricing tiers.

  • If your app is in an App Service Environment, it's already in a virtual network and doesn't require use of the VNet integration feature to reach resources in the same virtual network. 

 

  • Because there are many different customers in the same App Service scale unit, you can't connect the App Service network directly to your network.

  • Instead of connecting the networks, you need features to handle the various aspects of application communication.

MULTITENANT APP SERVICE NETWORKING FEATURES

 

Inbound features

Outbound features

App-assigned address

Hybrid Connections

Access restrictions

Gateway-required VNet Integration

Service endpoints

VNet Integration

Private endpoints

 

 

VNET Integration

  • Integrate your App Service with Azure virtual networks

  • Integrating Azure services to an Azure virtual network enables private access to the service from virtual machines or compute resources in the virtual network.

  • You can integrate Azure services in your virtual network with the following options:

    • Deploying dedicated instances of the service into a virtual network. The services can then be privately accessed within the virtual network and from on-premises networks.

    • Using Private Link to access privately a specific instance of the service from your virtual network and from on-premises networks.

    • You can also access the service using public endpoints by extending a virtual network to the service, through Service Endpoints.

      • Service Endpoints allow service resources to be secured to the virtual network.

  • Gateway-required virtual network integration

  • Gateway-required virtual network integration supports connecting to a virtual network in another region or to a classic virtual network.

    • Cross region vnet integration requires a vpn gateway and a point to site vpn connection.

  • Service endpoint is for regional or same region virtual network integration.

 

 

  • Virtual Network Integration supports only one virtual interface per worker.

  • One virtual interface per worker means one regional virtual network integration per App Service plan.

    • All the apps in the same App Service plan can use the same virtual network integration.

  • Apps in App Service are hosted on worker roles.

    • Regional virtual network integration works by mounting virtual interfaces to the worker roles with addresses in the delegated subnet.

    • Because the from address is in your virtual network, it can access most things in or through your virtual network like a VM in your virtual network would.

    • Virtual network integration doesn't enable your web apps to be accessed privately from a VM in the integration vnet

    • When regional virtual network integration is enabled, your app makes outbound calls through your virtual network.

      • The outbound addresses that are listed in the app properties portal are the addresses still used by your app.

      • However, if your outbound call is to a virtual machine or private endpoint in the integration virtual network or peered virtual network, the outbound address will be an address from the integration subnet.

App Settings

 

 

 

App Service General Configuration

  • Configure general settings

  • ARR affinity: In a multi-instance deployment, ensure that the client is routed to the same instance for the life of the session. You can set this option to Off for stateless applications.

 

  • Always On: Keep the app loaded even when there's no traffic.

    • By default, Always On is not enabled and the app is unloaded after 20 minutes without any incoming requests.

    • It's required for continuous WebJobs or for WebJobs that are triggered using a CRON expression.

  • Incoming client certificates: require client certificates in mutual authentication.

    • Check to make sure that your web app is not in the F1 or D1 tier as Custom SSL is not supported in the F1 or D1 tier.

 

App Configuration

 

 

Configure path mappings

 

  • Configure path mappings

  • By default, App Service starts your app from the root directory of your app code.

    • But certain web frameworks don't start in the root directory.

    • For example, Laravel starts in the public subdirectory.

      • Such an app would be accessible at http://contoso.com/public, for example, but you typically want to direct http://contoso.com to the public directory instead. 

  • For Windows apps, you can customize the IIS handler mappings and virtual applications and directories.

  • Handler mappings let you add custom script processors to handle requests for specific file extensions.

 

  • You can add custom storage for your containerized app.

  • Containerized apps include all Linux apps and also the Windows and Linux custom containers running on App Service.

    • Storage type: Azure Blobs or Azure Files. Windows container apps only support Azure Files.



 

Alerts and Action Groups

 

Diagnostics Logging

  • Enable diagnostics logging for apps in Azure App Service

  • Enable diagnostic logging

  • Application Logging allows you to store application logs in the Windows or Linux filesystem. For Windows VMs, they can also be sent to a blob.

    • The messages can be generated by the web framework you choose, or from your application code directly using the standard logging pattern of your language.

    • Each message is assigned one of the following categories: Critical, Error, Warning, Info, Debug, and Trace

    •  Application Logging (Filesystem) or Application Logging (Blob), or both.

      • The Filesystem option is for temporary debugging purposes, and turns itself off in 12 hours.

      • The Blob option is for long-term logging, and needs a blob storage container to write logs to.

  • Detailed Error Messaging can only be written to the local filesystem on Windows.

    • Copies of the .htm error pages that would have been sent to the client browser.

  • Failed Request tracing can only be written to the local filesystem on Windows.

    • Detailed tracing information on failed requests, including a trace of the IIS components used to process the request and the time taken in each component

  • WebServer logging can only be enabled for Windows machines.

    • It stores the IIS logs in the local file system or blob.

    • Raw HTTP request data in the W3C extended log file format.

    • Each log message includes data such as the HTTP method, resource URI, client IP, client port, user agent, response code, and so on.

  • Deployment logging for Windows and Linux on the local file system only.

    • Logs for when you publish content to an app. Deployment logging happens automatically and there are no configurable settings for deployment logging. 

 

 

  • ASP.NET applications can use the System.Diagnostics.Trace class to log information to the application diagnostics log.

  • System.Diagnostics.Trace.TraceError("If you're seeing this, something bad happened");

 

Configure Logging Via Azure AZ CLI

 

az webapp log

  • Configure logging for container (Configure gathering STDOUT and STDERR output from container.)

    • az webapp log config --docker-container-logging filesystem --name MyWebapp --resource-group MyResourceGroup

 

 

WebJobs

 

 

WebJob types

The following table describes the differences between continuous and triggered WebJobs.

Continuous

Triggered

Continuous

Triggered

Starts immediately when the WebJob is created. To keep the job from ending, the program or script typically does its work inside an endless loop. If the job does end, you can restart it. Typically used with WebJobs SDK.

Starts only when triggered manually or on a schedule.

Runs on all instances that the web app runs on. You can optionally restrict the WebJob to a single instance.

Runs on a single instance that Azure selects for load balancing.

Supports remote debugging.

Doesn't support remote debugging.

Code is deployed under \site\wwwroot\app_data\Jobs\Continuous.

Code is deployed under \site\wwwroot\app_data\Jobs\Triggered.

 

 

 

 

App Service On Linux

 

  • Run a custom container in Azure

  • App Service on Linux

  • App Service on Linux provides pre-defined application stacks on Linux with support for languages such as .NET, PHP, Node.js and others.

  • You can also use a custom Docker image to run your web app on an application stack that is not already defined in Azure.

  • Supported languages include: Node.js, Java (JRE 8 & JRE 11), PHP, Python, .NET Core, and Ruby.

  • If the runtime your application requires is not supported in the built-in images, you can deploy it with a custom container.

  • App Service on Linux is not supported on Shared pricing tier.

  • Outdated after January 21, 2021: You can't mix Windows and Linux apps in the same App Service plan.

  • You can get a list of new runtimes with az webapp list-runtimes --linux

    az webapp list-runtimes --linux [ "RUBY|2.5.5", "RUBY|2.6.2", "NODE|16-lts", "NODE|14-lts", "NODE|12-lts", "NODE|10-lts", "NODE|10.1", "NODE|10.10", "NODE|10.12", "NODE|10.14", "NODE|12.9", "PHP|7.2", "PHP|7.3", "PHP|7.4", "PHP|8.0", "DOTNETCORE|2.1", "DOTNETCORE|3.1", "DOTNETCORE|5.0", "DOTNETCORE|6.0", "TOMCAT|8.5-jre8", "TOMCAT|9.0-jre8", "JAVA|8-jre8", "WILDFLY|14-jre8", "JBOSSEAP|7-java8", "TOMCAT|8.5-java11", "TOMCAT|9.0-java11", "JAVA|11-java11", "JBOSSEAP|7-java11", "PYTHON|3.9", "PYTHON|3.8", "PYTHON|3.7", "PYTHON|3.6", "STATICSITE|1.0" ]

 

  • Linux and Windows App Service plans can now share resource groups.

    • This limitation has been lifted from the platform and existing resource groups have been updated to support this.

    • In the past, you needed a different resource group for Linux and Windows.

  • App Service on Linux is not supported on Shared pricing tier.

Use persistent shared storage

  • Configure a custom container for Azure App Service

  • You can use the /home directory in your custom container file system to persist files across restarts and share them across instances.

    • The /home directory is provided to enable your custom container to access persistent storage.

    • When persistent storage is disabled, then writes to the /home directory are not persisted across app restarts or across multiple instances.

    • When persistent storage is enabled, all writes to the /home directory are persisted and can be accessed by all instances of a scaled-out app.

    • Additionally, any contents inside the /home directory of the container are overwritten by any existing files already present on the persistent storage when the container starts.

    • By default, persistent storage is disabled on custom containers and the setting is exposed in the app settings. To enable it, set the WEBSITES_ENABLE_APP_SERVICE_STORAGE app setting value to true

    • For Windows containers, the mount point is C:\home

 

 

App Service And Containers

 

az appservice plan create -g MyResourceGroup -n MyPlan --is-linux --number-of-workers 4 --sku S1

 

az webapp create

Create a web app with an image from a private Azure Container Registry.

az webapp create -g MyResourceGroup --plan MyPlan --name MyUniqueAppName --deployment-container-image-name myregistry.azurecr.io/docker-image:tag


az webapp config container set

  • Set an existing web app's container settings

    • --docker-registry-server-password: The container registry server password.

    • --docker-registry-server-url: The container registry server url.

    • --docker-registry-server-user: The container registry server username.

 

Blocking Access To App

 

Using Your Custom Domain With Your App

#!/bin/bash fqdn=<Replace with www.{yourdomain}> webappname=mywebapp$RANDOM # Create a resource group. az group create --location westeurope --name myResourceGroup # Create an App Service plan in SHARED tier (minimum required by custom domains). az appservice plan create --name $webappname --resource-group myResourceGroup --sku SHARED # Create a web app. az webapp create --name $webappname --resource-group myResourceGroup \ --plan $webappname echo "Configure a CNAME record that maps $fqdn to $webappname.azurewebsites.net" read -p "Press [Enter] key when ready ..." # Before continuing, go to your DNS configuration UI for your custom domain and follow the # instructions at https://aka.ms/appservicecustomdns to configure a CNAME record for the # hostname "www" and point it your web app's default domain name. # Map your prepared custom domain name to the web app. az webapp config hostname add --webapp-name $webappname --resource-group myResourceGroup \ --hostname $fqdn echo "You can now browse to http://$fqdn"

 

TLS Mutual Auth

 

  • A certificate uploaded into an app is stored in a deployment unit that is bound to the app service plan's resource group and region combination (internally called a webspace).

    • This makes the certificate accessible to other apps in the same resource group and region combination.

  • Configure TLS mutual authentication for Azure App Service

  • In App Service, TLS termination of the request happens at the frontend load balancer.

  • When forwarding the request to your app code with client certificates enabled, App Service injects an X-ARR-ClientCert request header with the client certificate.

  • App Service does not do anything with this client certificate other than forwarding it to your app.

  • Your app code is responsible for validating the client certificate.

    • For ASP.NET apps only, the client certificate is available through the HttpRequest.ClientCertificate property.

    • For other application stacks (Node.js, PHP, etc.), the client cert is available in your app through a base64 encoded value in the X-ARR-ClientCert request header.

    • Access client certificate

 

Option

Description

Option

Description

Create a free App Service managed certificate

A private certificate that's free of charge and easy to use if you just need to secure your custom domain in App Service.

Purchase an App Service certificate

A private certificate that's managed by Azure. It combines the simplicity of automated certificate management and the flexibility of renewal and export options.

Import a certificate from Key Vault

Useful if you use Azure Key Vault to manage your certificates.

Upload a private certificate

If you already have a private certificate from a third-party provider, you can upload it.

Upload a public certificate

Public certificates are not used to secure custom domains, but you can load them into your code if you need them to access remote resources.

 

  • If you want to use a private certificate in App Service, your certificate must meet the following requirements:

    • Exported as a password-protected PFX file, encrypted using triple DES.

    • Contains private key at least 2048 bits long

    • Contains all intermediate certificates in the certificate chain

  • To secure a custom domain in a TLS binding, the certificate has additional requirements:

    • Contains an Extended Key Usage for server authentication (OID = 1.3.6.1.5.5.7.3.1)

    • Signed by a trusted certificate authority

 

  • To create custom TLS/SSL bindings or enable client certificates for your App Service app, your App Service plan must be in the Basic, Standard, Premium, or Isolated tier.

    • Custom SSL is not supported in the F1 or D1 tier.

  • The free App Service managed certificate is a turn-key solution for securing your custom DNS name in App Service.

    • It's a TLS/SSL server certificate that's fully managed by App Service and renewed continuously and automatically in six-month increments, 45 days before expiration.

  • If your certificate authority gives you multiple certificates in the certificate chain, you need to merge the certificates in order.

  • To export your certificate to PFX, run the following command.

    • Replace the placeholders <private-key-file> and <merged-certificate-file> with the paths to your private key and your merged certificate file.

openssl pkcs12 -export -out myserver.pfx -inkey <private-key-file> -in <merged-certificate-file>

 

  • When you enable mutual auth for your application, all paths under the root of your app require a client certificate for access.

    • To remove this requirement for certain paths, define exclusion paths as part of your application configuration.

 

  • If you visit the slot’s URL, you will get a Browser popup to specify the client certificate

 

Authentication

  • Authentication and authorization in Azure App Service and Azure Functions

  • Explore authentication and authorization in App Service

  • You're not required to use App Service for authentication and authorization.

    • Many web frameworks are bundled with security features, and you can use them if you like.

  • Azure App Service provides built-in authentication and authorization capabilities (sometimes referred to as "Easy Auth"), so you can sign in users and access data by writing minimal or no code in your web app, RESTful API, and mobile back end, and also Azure Functions. 

  • You're not required to use this feature for authentication and authorization.

    • You can use the bundled security features in your web framework of choice, or you can write your own utilities.

  • Azure App Service allows you to integrate a variety of auth capabilities into your web app or API without implementing them yourself.

  • It’s built directly into the platform and doesn’t require any particular language, SDK, security expertise, or even any code to utilize.

  • You can integrate with multiple login providers. For example, Azure AD, Facebook, Google, Twitter.

    • When you enable authentication and authorization with one of these providers, its sign-in endpoint is available for user authentication and for validation of authentication tokens from the provider.

 

  • App Service uses federated identity, in which a third-party identity provider manages the user identities and authentication flow for you.

  • Enabling this feature will cause all requests to your application to be automatically redirected to HTTPS, regardless of the App Service configuration setting to enforce HTTPS.

  • The authentication and authorization middleware component is a feature of the platform that runs on the same VM as your application. When it's enabled, every incoming HTTP request passes through it before being handled by your application.

  • The authentication and authorization module runs in the same sandbox as your application code.

    • When it's enabled, every incoming HTTP request passes through it before being handled by your application code.

    • This module handles several things for your app:

      • Authenticates users and clients with the specified identity provider(s)

      • Validates, stores, and refreshes OAuth tokens issued by the configured identity provider(s)

      • Manages the authenticated session

      • Injects identity information into HTTP request headers

 

The table below shows the steps of the authentication flow.

Step

Without provider SDK

With provider SDK

Step

Without provider SDK

With provider SDK