Custom claims provider (TokenIssuanceStart) not invoked during External ID user sign-in — endpoint receives zero requests despite ClaimsMappingPolicy attached

For a TokenIssuanceStart custom authentication extension that never fires, the supported diagnostics and configuration checks are limited to what is surfaced through the extension configuration, REST API validation, and Microsoft Entra sign-in logs.

From the documented behavior:

• When a custom claims provider is configured for token issuance, Microsoft Entra ID calls the configured REST API during the OnTokenIssuanceStart event, just before issuing the token to the application.
• If the REST API call fails or times out, the sign-in fails and the user/app receives a generic error; detailed error information is only visible in the sign-in logs.
• If the REST API is never called, there will be no corresponding entries in the REST API’s own logs, but the sign-in logs still show the authentication event information for the extension when it is invoked.

Given that the endpoint works when called directly and returns a valid onTokenIssuanceStart response, the remaining supported diagnostics and configuration checks are:

1. Verify that the extension is actually being invoked via sign-in logs
   • Go to Microsoft Entra admin center → Entra ID → Enterprise apps → Sign-in logs.
   • Open a sign-in that should have triggered the custom extension.
   • Select the Authentication Events tab.
   • Confirm whether there is an entry for the custom authentication extension call (including HTTP status, error code, execution duration, and retry count).
   • If there is no Authentication Events entry at all for the extension, Entra ID did not attempt to call the REST API for that sign-in.
2. Use sign-in logs + Azure Monitor for ongoing verification
   • Because the REST API call is fully controlled by Entra ID, the supported way to verify end-to-end invocation is via the Authentication Events data in sign-in logs.
   • Sign-in logs can be integrated with Azure Monitor to set alerts (for example, when the number of extension errors exceeds a threshold) and to visualize extension call volume over time.
   • This is the supported mechanism to confirm that the extension is being invoked during real user flows, beyond the REST API’s own logging.
3. Call the REST API directly with a token issued for the extension’s app registration
   • To validate that the REST API is correctly protected and accepts tokens issued for the extension’s resource app, obtain an access token using the documented client credentials flow:
     • In Entra admin center, locate the Azure Functions authentication events API (or equivalent) app registration used as the resource for the extension.
     • Create a client secret if needed.
     • Copy the Application ID URI from Expose an API.
     • Request a token from https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/token with:
       • grant_type=client_credentials
       • client_id = app’s client ID
       • client_secret = app’s secret
       • scope = {Application ID URI}/.default
     • Decode the token (for example, with https://jwt.ms) and confirm:
       • iss matches the issuer configured in the API
       • aud matches the client ID configured in the API
   • This confirms that the API protection and token validation logic match what Entra ID will use when invoking the extension.
4. Performance and timeout considerations
   • If the REST API is invoked but does not respond within the two-second timeout, Entra ID retries and then fails the authentication if all retries time out.
   • To avoid silent failures due to timeouts:
     • Cache access tokens for downstream APIs used by the extension.
     • Add detailed logging around calls to downstream services and measure their latency.
     • Use an Azure Functions Premium or Dedicated plan (or equivalent always-warm hosting) so the API is not cold-starting during sign-in.
   • Use API testing tools and automated integration tests to validate that the extension API consistently responds within the required time window.
5. Troubleshooting flow for a non-invoked extension
   • Confirm the extension is configured for OnTokenIssuanceStart and associated with the correct application.
   • Confirm the REST API is reachable and returns a valid response when called with a proper bearer token (already done).
   • Use sign-in logs → Authentication Events to verify whether Entra ID is attempting to call the extension at all.
   • If Authentication Events show no entry for the extension for any sign-in, the issue is in how the extension is wired into the user flow or application, not in the REST API itself.
   • If Authentication Events show entries with errors, use the HTTP status, error code, and duration from those entries to guide further debugging.

Regarding the specific error codes (AADSTS1100001, AADSTS1003011), tenant-level toggles, or undocumented feature flags/licensing for External ID custom claims providers, there is no additional actionable information in the provided documentation beyond using sign-in logs and the above diagnostics. The documented and supported way to verify invocation is via Microsoft Entra sign-in logs → Authentication Events, combined with the REST API’s own logging and performance testing.

References:

• Troubleshoot your custom authentication extension
• Extend authentication flows with your own business logic
• Tutorial: Add sign-in and sign-out in iOS/macOS app by using native authentication
• Tutorial: Sign in user automatically after sign-up in an iOS/macOS app
• Tutorial: Add sign-in in Android app by using native authentication