Built In Authentication

If authentication is enabled, do not copy the source auth payload wholesale. Provider registrations, client secrets, Key Vault references, audiences, and redirect URIs can be app-specific. Never display or persist provider secrets.

Get the target hostname:

For each enabled provider, identify the target callback URI required by that provider. Easy Auth callback URIs generally use https://<TARGET_HOSTNAME>/.auth/login/<PROVIDER>/callback, but verify the exact URI against the provider-specific instructions in Configure built-in authentication (opens in a new tab).

Use ask_user:

The source app uses built-in authentication with <PROVIDERS>. Authentication registrations and secrets aren’t transferred automatically. How should we handle authentication for <NEW_APP_NAME>?

1. Configure and validate now (recommended) — guide provider-by-provider recreation and verify the target before deployment.
2. Defer the migration — leave application code undeployed until authentication is configured and verified.

If deferred, record the enabled providers and target callback URIs in <UPGRADE_DIR>/upgrade-status.md without secrets. Mark this step deferred — built-in authentication not configured and stop before Step 5. Do not deploy code or run target HTTP validation while the authentication boundary is absent.

If configuring now:

1. For each provider, ask whether to reuse its existing registration or create a target-specific registration. Obtain approval before changing an external identity-provider registration.

2. Guide the user through the provider-specific configuration. Don’t request secrets in chat or place them in migration artifacts; have the user configure them directly through the portal, an existing secret-bearing app setting, or a Key Vault reference.

3. Ensure the target callback URI is registered with the provider.

4. Verify the target using the same safe projection used in Step 3c:

   bashCopy

   az webapp auth show --name <NEW_APP_NAME> --resource-group <RESOURCE_GROUP> --query "{enabled:enabled,unauthenticatedClientAction:unauthenticatedClientAction,defaultProvider:defaultProvider,tokenStoreEnabled:tokenStoreEnabled,allowedAudiences:allowedAudiences,allowedExternalRedirectUrls:allowedExternalRedirectUrls,isAuthFromFile:isAuthFromFile,providers:{aadClientId:clientId,githubClientId:gitHubClientId,googleClientId:googleClientId,facebookAppId:facebookAppId,twitterConsumerKey:twitterConsumerKey,microsoftAccountClientId:microsoftAccountClientId}}" -o json

Compare enabled state, unauthenticated behavior, default provider, allowed audiences and redirects, token-store state, and configured provider identifiers. Record intentional differences. Mark the step complete only after the target provider configuration and callback URI are verified.

Do not use an enable-only az webapp auth update command as a substitute for recreating the provider configuration.