Azure Functions Easy Auth: Interactive login works with an invalid clientSecretSettingName app setting but fails when the Entra App Registration secret is deleted

Apurva Pathak 960 Reputation points
2026-10-29T12:18:16.31+00:00

PS: The question is drafted with the help of AI because this seems a complex issue, and I was finding it hard to explain everything smoothly.

Question

I am troubleshooting an unexpected behaviour with Microsoft Entra ID authentication in an Azure Function App using App Service Authentication (Easy Auth V2).

Configuration

My Function App is configured under Settings → Authentication → Microsoft identity provider and uses a Microsoft Entra App Registration.

The provider configuration references the following application setting for its client secret:

MICROSOFT_PROVIDER_AUTHENTICATION_SECRET

The App Registration has only one client secret. There are no other client secrets configured for this application.

My Function code does not read this setting or implement custom authentication. Authentication is handled by the Azure platform through Easy Auth.

Tests performed and results

I have performed the following controlled tests:
Test App Registration client secret Function App setting Result
1 Valid secret exists Correct value Interactive login works
2 Valid secret exists Deliberately incorrect value Interactive login continues to work
3 Secret deleted Incorrect value remains Interactive login fails within approximately two minutes
4 New valid secret created Incorrect value remains unchanged Interactive login starts working again

For Test 2, I changed the deployed application setting to a deliberately invalid value, restarted the Function App, and verified the configuration. The setting remained incorrect for months while authentication continued to work.

For Tests 3 and 4, the only change to the App Registration was deleting its existing client secret and subsequently creating a new one. The Function App setting remained unchanged throughout.

The failure specifically affects interactive authentication through Easy Auth, such as /.auth/login/aad. I am not claiming that these tests demonstrate a failure of ordinary inbound bearer-token validation.

What I am trying to understand

My understanding is that the V2 configuration property:

identityProviders.azureActiveDirectory.registration.clientSecretSettingName

identifies the application setting from which Easy Auth obtains the client secret.

If this property points to MICROSOFT_PROVIDER_AUTHENTICATION_SECRET, I would expect the value in that setting to be presented during the OAuth authorization-code exchange.

However, the tests above suggest that Easy Auth continues to authenticate successfully when that value is demonstrably incorrect, yet fails when the actual client secret is deleted from the Entra App Registration.

I understand that Microsoft Entra does not allow an application to retrieve an existing client-secret value after creation. I am therefore not assuming that Easy Auth can simply retrieve the secret from the App Registration.

Questions for the Azure App Service Authentication team

What documented mechanism could explain this behaviour? Why would deleting the only client secret from the App Registration break interactive login when the configured application setting contains an incorrect value?

Under what circumstances can Easy Auth obtain or use a client credential other than the value referenced by clientSecretSettingName? For example, could managed identity, a federated identity credential, file-based authentication configuration, legacy V1 settings, or another supported mechanism explain this behaviour?

Could the existence of a valid client secret on the App Registration affect Easy Auth's interactive login even when the application setting referenced by clientSecretSettingName is invalid? If so, what is the underlying mechanism?

Which diagnostic logs or correlation identifiers can establish whether Easy Auth is performing a client-secret-based token exchange, using an alternative credential, or following a different OAuth flow?

Are there known behaviours or documented exceptions in Easy Auth V2 that could account for this scenario?

I would appreciate an explanation grounded in the documented implementation or confirmation from the Azure App Service Authentication team. I am particularly interested in understanding which credential Easy Auth actually uses during the authorization-code exchange.

Thank you.

Azure Functions
Azure Functions

An Azure service that provides an event-driven serverless compute platform.

2 answers

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-10-29T15:02:02.38+00:00

    The documented Easy Auth V2 behavior does not explain these test results: an incorrect value in the app setting named by clientSecretSettingName should not become valid merely because some other valid secret exists on the app registration.

    Documented behavior

    identityProviders.azureActiveDirectory.registration.clientSecretSettingName is defined as the app-setting name that contains the relying-party application's client secret.^1^ For an automatically created registration, the portal normally stores that value in the slot-sticky MICROSOFT_PROVIDER_AUTHENTICATION_SECRET setting.^2^

    Easy Auth's documented flow selection is:

    • Secret configured: Easy Auth acts as a confidential client, requests code id_token, and exchanges the authorization code using the secret.
    • No secret configured: Easy Auth falls back to response_type=id_token, the implicit flow, without a server-side code exchange.^3^

    Consequently, the documented confidential-client path would require the actual secret value. Entra cannot authenticate an incorrect value based only on the existence of another credential.

    There is no public documentation here establishing that Easy Auth:

    • retrieves a secret value from an app registration;
    • selects an arbitrary valid secret attached to that registration;
    • treats the mere presence of a secret as proof of client identity; or
    • falls back from an invalid configured secret to another app-registration credential.

    The observed “delete any valid secret → failure; create an unrelated secret → success” behavior therefore needs runtime evidence and App Service support investigation. It should not be treated as a supported credential-selection mechanism.

    Supported alternative credentials

    These alternatives apply only when explicitly configured:

    1. Managed identity with federated identity credentials Easy Auth supports this through a specific override:
      • Create the federated identity credential on the app registration.
      • Add OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID as an app setting whose value is the managed identity’s client ID.
      • Set clientSecretSettingName itself to OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.
      It does not silently select the Function App’s managed identity merely because one is enabled.^2^
    2. Certificate credential The V2 schema exposes clientSecretCertificateThumbprint, clientSecretCertificateIssuer, and clientSecretCertificateSubjectAlternativeName as alternatives to a client secret.^4^ Check the effective V2 resource for these properties; do not infer their use from certificates merely existing on the app registration.
    3. File-based configuration If platform.configFilePath is populated, the referenced file defines Easy Auth behavior instead of the normal ARM configuration. On Linux, this must be an absolute path such as /home/site/wwwroot/auth.json.^5^
    4. Legacy V1 state V1 stored secrets differently. Migration to V2 moves them into slot-sticky application settings. Inspecting both configurations is appropriate for an app with migration history, although the portal authentication experience requires V2.^6^

    Establish the effective path

    Capture the effective configuration without printing any secret values:

    az webapp auth show \
  --resource-group <resource-group> \
  --name <function-app>

az functionapp config appsettings list \
  --resource-group <resource-group> \
  --name <function-app> \
  --query "[?contains(name, 'AUTH') || contains(name, 'OVERRIDE')].name"

    For a deployment slot, target the slot explicitly. Check:

    • platform.configFilePath
    • platform.runtimeVersion
    • clientSecretSettingName
    • all three certificate properties
    • whether OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID is selected
    • whether the inspected resource is the production site or a slot

    Run each new login in a fresh private-browser session. Easy Auth caches tokens for an authenticated session, and Microsoft recommends signing out or using a newly opened private session after authentication changes.^7^

    Logs that can distinguish the flow

    Enable App Service application logging and failed-request tracing. Authentication traces appear in the application logs; failed-request traces identify the EasyAuthModule_32/64 module on Windows.^3^

    Also route App Service authentication resource logs to Log Analytics. The AppServiceAuthenticationLogs table includes CorrelationId, Details, Message, OperationName, StatusCode, ModuleRuntimeVersion, and UTC TimeGenerated.^8^

    AppServiceAuthenticationLogs
| where TimeGenerated > ago(30m)
| where SiteName =~ "<function-app-name>"
| project TimeGenerated, CorrelationId, OperationName,
          StatusCode, Level, Message, Details, ModuleRuntimeVersion
| order by TimeGenerated asc

    Correlate the failed attempt with Entra ID → Sign-in logs or Diagnose & solve problems → Sign-in Diagnostic using the application, UTC timestamp, correlation ID, or request ID.^9^

    If the logs do not identify the credential type, open an Azure support case for App Service Authentication, providing:

    • Function App resource ID and slot;
    • UTC timestamps for one success and one failure;
    • Easy Auth and Entra correlation/request IDs;
    • redacted authsettingsV2;
    • authentication runtime version;
    • the four-test matrix;
    • confirmation that each test used a new private session.

    Microsoft support would need platform-side traces to confirm whether this is cached or hidden auto-provisioned state, a runtime defect, or another undocumented implementation detail.

    References

    1. Microsoft.Web/sites/config 'authsettingsV2' - Bicep, ARM template ...
    2. Configure your App Service or Azure Functions app to use Microsoft Entra sign-in
    3. Authentication and authorization in Azure App Service and Azure Functions
    4. Microsoft.Web sites/slots/config 'authsettingsV2' 2022-09-01 (deployment-language-arm-template)
    5. Configure authentication in Azure App Service by using a configuration file
    6. Manage Authentication and Authorization API Versions - Azure App Service
    7. Tutorial: Authenticate and authorize users end-to-end in Azure App Service (platform-windows)
    8. AppServiceAuthenticationLogs
    9. What is the Sign-in diagnostic in Microsoft Entra ID?
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Hemant Bharadwaj 90 Reputation points Microsoft Employee
    2026-10-29T14:59:35.2166667+00:00

    Likely cause: your observation is consistent with Easy Auth configuration/credential source divergence (or cached effective auth settings), not with normal token-validation behavior in your function code.

     

    Your test sequence strongly suggests Easy Auth is not always reading the exact runtime value you expect from clientSecretSettingName during every interactive auth flow step, or another effective credential/config path is active.

     

    1. Confirm the effective Easy Auth V2 configuration

     

    1. Validate app settings and slot scope
      • Check whether MICROSOFT_PROVIDER_AUTHENTICATION_SECRET differs between production slot and deployment slots.
      • Verify no Key Vault reference or platform setting indirection is resolving to a different secret than expected.

     

    1. Force config re-read and retest

     

    1. Compare with Entra app secret lifecycle events
      • Your tests 3/4 indicate login failure aligns with actual Entra secret deletion, even when app setting stayed unchanged.
      • Treat this as evidence that the interactive code-exchange path still depends on a valid Entra credential tied to the app registration.

     

    1. Collect diagnostics for product-team confirmation

     

    Validation checks:

    • /.auth/login/aad success/failure after each controlled change (one variable at a time).
    • Correlation between Entra secret deletion/recreation and Easy Auth interactive login state.
    • Effective authsettingsV2 matches intended clientSecretSettingName source.

     

    Confirmed vs possible:

    • Confirmed: deleting the Entra app secret breaks interactive login in your environment.
    • Possible: cached/alternate credential path, slot/config mismatch, or undocumented provider fallback behavior requiring support trace confirmation.

     

    “If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.”

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.