Is Azure App Service ARR Affinity Required to be Enabled?

For my web app, the redirect from Azure AD back to the web app after successful sign-in requires that I enable ARR Affinity on the web app if it is scaled out to more than one instance, otherwise an infinite redirect loop between my web app and Azure AD ensues. I don’t believe this should be a requirement so I’d like to understand what I have misconfigured. There should be no problem with a different backend instance of a web app handling the redirect back from Azure AD and accepting the JWT token.

Which Version of MSAL are you using ? Microsoft.Identity.Client 4.30.0 Microsoft.Identity.Web 1.9.1 Microsoft.Identity.WebUI 1.9.1

Platform netcore 3.1 on Linux Docker container in Azure App Service.

What authentication flow has the issue?

• Web App
  • Whatever is the default

Is this a new or existing app? This is a new app or experiment

Repro

services.AddMicrosoftIdentityWebAppAuthentication(Configuration);

    "AzureAd": {
        "Instance": "https://login.microsoftonline.com/",
        "Domain": "XXX",
        "TenantId": "XXX",
        "ClientId": "XXX",
        "CallbackPath": "/signin",
        "SignedOutCallbackPath": "/signout"
    },

Web App scaled out to 2 instances, disable ARR Affinity on web app

Expected behavior App redirects to Azure AD to sign-in user, authenticated user is redirected back to web app and can now use app.

Actual behavior

• App redirects to Azure AD to sign-in user, authenticated user is redirected back to web app.
• App redirects to Azure AD to sign-in user, authenticated user is redirected back to web app.
• App redirects to Azure AD to sign-in user, authenticated user is redirected back to web app.
• … (loop)

Web App scaled out to 2 instances, enable ARR Affinity on web app

Expected and Actual behavior App redirects to Azure AD to sign-in user, authenticated user is redirected back to web app and can now use app.

Web App scaled down to 1 instance, disable ARR Affinity on web app

Expected and Actual behavior App redirects to Azure AD to sign-in user, authenticated user is redirected back to web app and can now use app.

[jmprieur]

Thanks very much @krispenner for these detailed analysis and explanations. I’ve added the explanations to the wiki: https://github.com/AzureAD/microsoft-identity-web/wiki/Deploying-web-apps-to-App-Services-as-Linux-containers#issue-with-scaled-out-web-apps-in-app-services

[krispenner]

So it seems that the ASP .NET Core data protection (DP) keys are not automatically sync’d across backend App Service instances of the same app. I’m sure this is meant to be automatic, but maybe not for Linux based App Services (containers) but only for Windows based web apps. Anyways, I have added my own encryption key to be shared across instances and it’s hosted in blob storage and secured via key vault. By ensuring the DP key is shared across all instances of the Linux App Service the Open ID Connect message state parameter is being properly decrypted on any backend instance of the web app.

@jmprieur I’d suggest you make note of this in your documentation for anyone trying to use Microsoft.Identity.Web in a scaled out Linux App Service as this is required unless they enable the session affinity cookie on the web app which is not ideal.

services.AddDataProtection()
    .SetApplicationName("MyApp")
    .SetDefaultKeyLifetime(TimeSpan.FromDays(30))
    .PersistKeysToAzureBlobStorage(new Uri("https://mystore.blob.core.windows.net/keyrings/master.xml"), new DefaultAzureCredential())
    .ProtectKeysWithAzureKeyVault(new Uri("https://myvault.vault.azure.net/keys/MasterEncryptionKey"), new DefaultAzureCredential());