Troubleshooting Microsoft External ID custom authentication extensions

Question

Troubleshooting Microsoft External ID custom authentication extensions

Sergio Passalacqua 20

Hello

I have setup a new external id tenant. I have two customer authentication extensions

AttributeCollectionSubmit

TokenIssuanceStart

Each call different endpoint on the same api.

I setup external ID to federate to my production Entra ID. I then create a user flow, app registation, etc. I then run the user flow, I get to the new user signup page, fill out the fields but when I press next I then I get error

"Something went wrong. Contact your IT department if the problem persists."

Looking at the developer tools in edge, I see the error

{

"error": {

    "code": 6000,

    "correlationId": "f22236f8-4145-41a6-90ab-0118e4ed2f20",

    "timestamp": "2026-05-20 20:28:02Z",

    "isFatal": true,

    "message": "AADSTS1100001"

}

}

I specifically set these endpoints being called by the custom auth extension to allow anonymous and override authentication because I am not able to see any evidence at all in application insights that the API is even called.

ex route

    [HttpPost]

    [AllowAnonymous]

    [OverrideAuthentication]

    [Route("create")]

    public async Task<IHttpActionResult> Create()

Note these apis are .NEt apis running in AKS in a separate tenant (my production tenant).

I have tested the API independently of azure external ID, using postman. Returns the appropriate payload.

Can someone help me understand what's going on? How do I troubleshoot this. I've hit a dead end and we have a major deliverable with a customer.

Sergio Passalacqua 20

I reviewed the sign in logs, and there aren't any for this user. No sign in logs, no application insights logs for my app.

My REST api for the AttributeCollectionSubmit event is very simple on purpose. When I call it directly, it logs appropriately and returns expected result

    [HttpPost]

    [AllowAnonymous]

    [OverrideAuthentication]

    [Route("create")]

    public async Task<IHttpActionResult> Create()

    {

        var continueResponse = NewUserSignUpResponse.Continue();

        try

        {

            var rawBody = Request.Content != null

                ? await Request.Content.ReadAsStringAsync()

                : string.Empty;

            string correlationId = null;

            try

            {

                var payload = JsonConvert.DeserializeObject<NewUserSignUpPayload>(rawBody);

                correlationId = payload?.Data?.AuthenticationContext?.CorrelationId;

            }

            catch { /* correlationId stays null if body can't be parsed */ }

            Log.Information(

                "NewUserSignUp received. CorrelationId: {CorrelationId} Body: {Body}",

                correlationId, rawBody);

        }

        catch (Exception ex)

        {

            Log.Error(ex, "NewUserSignUp: error during logging");

        }

        return Ok(continueResponse);

    }

Sergio Passalacqua 20 Reputation points

2026-05-20T21:13:19.36+00:00

Here is the sample output from the create endpoint

{ "data": { "@odata.type": "microsoft.graph.onAttributeCollectionSubmitResponseData", "actions": [ { "@odata.type": "microsoft.graph.attributeCollectionSubmit.continueWithDefaultBehavior" } ] }}
Yevhen Herasimov 25 Reputation points

2026-05-21T16:35:55.31+00:00

I have exactly the same problem. Cannot make AttributeCollectionSubmit custom authentication extention working. Existing custom authentication extention are still working, but I cannot setup a new one. I have tried this on two different tenants.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-05-26T19:49:33.7766667+00:00
Hello Sergio Passalacqua,

Based on the details shared, the payload and controller logic look correct. Since the API works from Postman, but there are no Application Insights or sign-in logs, the request is likely failing before it reaches the API.

Please validate that:

the endpoint is publicly reachable from Microsoft services,

there are no ingress/WAF restrictions, redirects, or auth challenges,

TLS 1.2 and a trusted public certificate are configured,

and ingress or reverse proxy logs show whether the request reaches the cluster.

Also confirm the API returns HTTP 200 with Content-Type: application/json and no additional wrapper objects.

Your response format looks valid for AttributeCollectionSubmit.

Another area to verify is the custom authentication extension configuration itself, including the authentication type, app registration/service principal, and resource configuration.
Yevhen Herasimov 25 Reputation points

2026-05-27T08:38:10.7666667+00:00

Here is the related issue. https://learn.microsoft.com/en-us/answers/questions/5901393/newly-created-custom-claims-providers-dont-trigger.
I also have created a separate Entra External Id tenant. And the issue is easily reproducable there as well. Basically it is not possible to make Entra call your newly created custom authentication extension API. Previously created extensions (1 month ago) still work fine, but I cannot make any newly added extension to work. Can this be escalated to EntraId team?

1 answer

Your answer

Sergio Passalacqua 20 Reputation points

2026-05-20T21:10:38.0833333+00:00

I reviewed the sign in logs, and there aren't any for this user. No sign in logs, no application insights logs for my app.

My REST api for the AttributeCollectionSubmit event is very simple on purpose. When I call it directly, it logs appropriately and returns expected result

[HttpPost] [AllowAnonymous] [OverrideAuthentication] [Route("create")] public async Task<IHttpActionResult> Create() { var continueResponse = NewUserSignUpResponse.Continue(); try { var rawBody = Request.Content != null ? await Request.Content.ReadAsStringAsync() : string.Empty; string correlationId = null; try { var payload = JsonConvert.DeserializeObject<NewUserSignUpPayload>(rawBody); correlationId = payload?.Data?.AuthenticationContext?.CorrelationId; } catch { /* correlationId stays null if body can't be parsed */ } Log.Information( "NewUserSignUp received. CorrelationId: {CorrelationId} Body: {Body}", correlationId, rawBody); } catch (Exception ex) { Log.Error(ex, "NewUserSignUp: error during logging"); } return Ok(continueResponse); }
Sergio Passalacqua 20 Reputation points

2026-05-20T21:13:19.36+00:00

Here is the sample output from the create endpoint

{ "data": { "@odata.type": "microsoft.graph.onAttributeCollectionSubmitResponseData", "actions": [ { "@odata.type": "microsoft.graph.attributeCollectionSubmit.continueWithDefaultBehavior" } ] }}
Yevhen Herasimov 25 Reputation points

2026-05-21T16:35:55.31+00:00

I have exactly the same problem. Cannot make AttributeCollectionSubmit custom authentication extention working. Existing custom authentication extention are still working, but I cannot setup a new one. I have tried this on two different tenants.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-05-26T19:49:33.7766667+00:00

Hello Sergio Passalacqua,

Based on the details shared, the payload and controller logic look correct. Since the API works from Postman, but there are no Application Insights or sign-in logs, the request is likely failing before it reaches the API.

Please validate that:

the endpoint is publicly reachable from Microsoft services,

there are no ingress/WAF restrictions, redirects, or auth challenges,

TLS 1.2 and a trusted public certificate are configured,

and ingress or reverse proxy logs show whether the request reaches the cluster.

Also confirm the API returns HTTP 200 with Content-Type: application/json and no additional wrapper objects.

Your response format looks valid for AttributeCollectionSubmit.

Another area to verify is the custom authentication extension configuration itself, including the authentication type, app registration/service principal, and resource configuration.
Yevhen Herasimov 25 Reputation points

2026-05-27T08:38:10.7666667+00:00

Here is the related issue. https://learn.microsoft.com/en-us/answers/questions/5901393/newly-created-custom-claims-providers-dont-trigger.
I also have created a separate Entra External Id tenant. And the issue is easily reproducable there as well. Basically it is not possible to make Entra call your newly created custom authentication extension API. Previously created extensions (1 month ago) still work fine, but I cannot make any newly added extension to work. Can this be escalated to EntraId team?

Answer 1

Use the sign-in logs and the custom extension error codes to understand what is failing and whether the REST API is being called at all.

Check Microsoft Entra sign-in logs for the exact custom extension error
1. In the external tenant, go to Microsoft Entra admin center → Entra ID → Enterprise apps → Sign-in logs.
2. Open the latest failed sign-in that corresponds to the correlation ID/time.
3. Select the Authentication Events tab.
4. In this tab, look for:
  - HTTP status for the custom extension call
  - Custom extension error code (1003xxx)
  - Execution duration and retry count This tells whether the extension was invoked and what error Entra ID saw.
Map the error from logs to the custom extension error table In the Authentication Events details, find the errorCode in the 1003000–1003027 range and match it to the documented meanings:
- 1003005 CustomExtensionTimedOut: API didn’t respond within the allowed timeout or token invalid.
- 1003007/1003009 CustomExtensionNullClaimsResponse / CustomExtensionEmptyResponse: body missing or null.
- 1003006 CustomExtensionInvalidResponseContentType: content-type not application/json.
- 1003002/1003003/1003008/1003010/1003012: response schema or action type invalid.
- 1003014/1003015/1003020: configuration issues with identifierUris, domain name, or target URL.
- 1003021: missing CustomAuthenticationExtensions.Receive.Payload permission.
- 1003027: connection error to the API.
Use the exact code from the sign-in log to narrow down whether this is:
- A configuration problem (resourceId, targetUrl, permissions, URL format), or
- A runtime problem (timeout, invalid response, content type, etc.).
Verify custom extension configuration (resourceId/targetUrl) Based on the error codes reference:
- Ensure the targetUrl and resourceId share the same fully qualified domain name (avoid 1003015 CustomExtensionDomainNameDoesNotMatch).
- Ensure the resourceId appId corresponds to an existing service principal in the external tenant (avoid 1003016/1003017/1003019).
- Ensure the targetUrl is a valid https URL (avoid 1003020 CustomExtensionIncorrectTargetUrlFormat).
- Ensure the Microsoft Graph service principal is present and enabled (avoid 1003022).
- Ensure the endpoint is not blocked (avoid 1003023).
Verify permissions for the custom extension resource app
- In the external tenant, open the app registration used as the resourceId for the custom extension.
- Confirm that admin consent has been granted for the Microsoft Graph CustomAuthenticationExtensions.Receive.Payload app role (application permission) to the service principal that represents the custom extension client (avoid 1003021 CustomExtensionPermissionNotGrantedToServicePrincipal).
Call the REST API directly with a proper Entra access token Because the API is in another tenant and you currently allow anonymous, confirm that the extension can reach it and that it behaves correctly when called as Entra expects:
1. In the external tenant, open the Azure Functions authentication events API (or equivalent) app registration used for the custom extension.
2. Create a client secret if not already present.
3. From Expose an API, copy the Application ID URI (for example api://contoso.azurewebsites.net/aaaabbbb-0000-cccc-1111-dddd2222eeee).
4. In an API testing tool, request a token:
  - POST to https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/token.
  - Body (form-data):
    - grant_type: client_credentials
    - client_id: client ID of the application
    - client_secret: its client secret
    - scope: {Application ID URI}/.default
5. Decode the access_token (for example with https://jwt.ms) and verify:
  - iss matches the issuer configured in the API.
  - aud matches the client ID configured in the API.
6. Use this token as a Bearer token and call the same endpoints (create, etc.) that the custom extensions use, with the same request body shape expected by the extension type.
If the API fails when called with this token or with the Entra extension payload, fix:
- Authentication/authorization logic in the API (even if currently overridden).
- Response content-type (application/json).
- Response schema (must match the custom extension type’s schema).
Confirm the API is reachable and not timing out If the sign-in logs show 1003005 CustomExtensionTimedOut or 1003027 CustomExtensionConnectionError:
- Check network connectivity from Entra to the AKS-hosted API (public DNS, firewall, IP restrictions, TLS cert validity).
- Ensure the API responds within the two-second timeout window. If there are downstream calls, add logging for their durations and consider caching tokens and using a “warm” hosting plan as recommended.
Enable and use detailed logging on the API side The platform hosting the API (for example, Azure Functions or other API platform) should log:
- All incoming requests (method, path, correlation IDs if passed, timestamps).
- Response status codes and durations.
- Any exceptions when parsing the Entra extension payload.
If no requests appear at all during a sign-in attempt, the problem is in custom extension configuration or Entra’s ability to reach the endpoint (use sign-in logs and error codes to pinpoint). If requests appear but sign-in still fails, align the response format with the extension’s expected schema.
Performance and reliability checks If performance-related errors appear (timeouts, throttling):
- Cache any downstream access tokens.
- Log and optimize calls to downstream services.
- Host the API on a plan that keeps it warm (for example, Premium or Dedicated for Azure Functions).
- Use automated integration tests or API testing tools to validate performance against the two-second limit.

By combining the Authentication Events details in sign-in logs with the custom extension error codes and a direct, token-based call to the API, it becomes clear whether the issue is configuration (resourceId/targetUrl/permissions), connectivity, timeout, or response schema/content-type.

References: