Microsoft Security | Microsoft Identity Manager
A tool for managing user identities, credentials, and access across on-premises and cloud environments
Entra External ID CIAM extensions not binding to proven Functions Endpoint
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(112.00000000000001, 76%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERC%3C/text%3E%3C/svg%3E)
Richard Collins
21
Reputation points
Issue summary
After 21 hours of trials and attempts we cannot see what is left to try.
Simply sign up works end to end. When the simplest of functions is added, which just opens and returns and logs okay, it returns and the signup aborts with message.
We are unable to complete a CIAM custom authentication extension (Before/After) for a working Azure Functions HTTP endpoint. Despite the Function executing and returning a valid CIAM‑compliant response, the CIAM user flow fails immediately after the callback with:
AADSTS1100001: Non-retryable error has occurred.
Underlying error code: 1003009
Based on repeated, clean-room repros and screenshots, the CIAM extension wizard in our tenant intermittently fails to expose or honor the “Resource application” selector and/or binds the extension to the wrong application (client app) instead of our Resource API application, causing audience mismatch and the consistent 1003009 failure.
Environment
- Tenant (External ID / CIAM): IRSLOBBY – Tenant ID
8299aefb-503c-48f5-bc8c-293d6acdf888 - User flow:
PPXMFlow - Function App (Windows classic Consumption / Y1):
ciamprovingy1(Node ~24) - Function (v3 model):
CIAMproofat routePOST /api/ciam/proof - Function returns CIAM‑compliant schema:
{"version":"1.0.0","action":"Continue","userAttributes":[],"userDefinedClaims":[{"claimId":"echoEventType","value":"..."}]} - API (Resource) application intended for binding:
CIAMprovingAPIclean- App ID:
8cd9257d-a7b6-4a76-aa7c-80e1560ee36f- Application ID URI:
api://ciamprovingy1.azurewebsites.net/8cd9257d-a7b6-4a76-aa7c-80e1560ee36f- (Has a Service Principal; signInAudience set to multi‑tenant + MSA; exposes a simple “access” scope or, under new CIAM model, uses the built‑in “Receive custom authentication extension HTTP requests” binding.)
- Application ID URI:
- App ID:
What works (proven)
- The Function endpoint is reachable and executes successfully from CIAM:
- Logs (multiple times) show:
- `Request successfully matched the route 'api/ciam/proof'` - `AuthenticationScheme: WebJobsAuthLevel was successfully authenticated.` - `Executing 'Functions.CIAMproof' …` - **`[CIAMProof] event=microsoft.graph.authenticationEvent.attributeCollectionStart`** - `Executed 'Functions.CIAMproof' (Succeeded, Duration≈7–25ms)` - Manual `curl` POST to the function with a valid function/host key returns HTTP 200 and the expected CIAM JSON. - Function discovery is now stable (v3 structure: `/wwwroot/host.json` + `/wwwroot/CIAMproof/function.json,index.js`).
- Logs (multiple times) show:
Conclusion: The Function App is not the problem. The failure happens after we return 200—inside CIAM’s validation.
What fails (symptoms)
Immediately after the Function returns 200 OK, CIAM fails the step with AADSTS1100001 / 1003009. Representative instances (UTC):
- 2026‑03‑15 20:14:05Z — Request Id
a17d9cb4-1854-43a1-9c36-917a095b0100, Correlation Id5d0d918b-2006-4fd7-b0a6-ad896cff9f94 - 2026‑03‑15 22:21:56Z — Request Id
9477a325-06ba-4c7d-a2b2-f5f8527f0100, Correlation Id82db1baa-9e80-4afc-b441-8af3516bb092 - 2026‑03‑15 22:29:24Z — Request Id
ab7b01bb-6aef-4a30-832a-da4957f90000, Correlation Id2841489d-9419-424f-ab04-00dc4ed5dd31 - 2026‑03‑16 00:31:28Z — Request Id
8cf4b6b5-85fd-4a50-8152-382ae7a40100, Correlation Id09256dcb-1e6c-44cb-8e15-db1d50823e6c - 2026‑03‑16 14:02:38Z — Request Id
093b5827-8467-42dc-820e-32b4b5530300, Correlation Id2155dfef-a5c5-4939-8357-ad86899e7ed8
Observation: These errors occur only when the extension is attached; user flow without the extension completes and creates the user successfully.
Attempts already made (chronology & highlights)
Function side
- Migrated off Flex Consumption (v4 model) to Windows classic Y1; rebuilt as Node v3 with
function.json+index.js.- Verified portal “Code + Test” and Application Insights show successful invocations with expected event types.
- Confirmed Function keys/host keys and correct URL with
?code=.
- Created **`CIAMprovingAPIclean`** as a clean API app. - Set **Application ID URI** to the Function hostname + appId. - Ensured Service Principal exists; signInAudience is multi‑tenant/MSA. - In newer CIAM UI, “Required permission: Receive custom authentication extension HTTP requests” is displayed (no legacy scope picker). **Service principal visibility & audience** - Ensured the **Resource application** SP appears in Enterprise applications (verified). - Confirmed visible `servicePrincipalNames` include both the GUID and the Application ID URI. **Extension creation – multiple rounds (Edge/Chrome/Firefox)** - Created **Before** extensions via “Create new app registration” **and** via “Select an existing app registration”. - Reproduced on fresh browser sessions (incl. Firefox just installed), new tabs, and with >5–8s hydration waits on each wizard panel. - **Consistent anomaly**: The **API Authentication** panel often **omits** the **“Resource application: Change”** block entirely; when it appears, selecting `CIAMprovingAPIclean` does not always persist back to the summary, which then shows: - **Resource application = a newly generated client app** (e.g., `Extra001`, `CIAMautobuild2`, `CIAMprovingy1Before`) - **Required app ID URI = `api://…/{appid}`** (placeholder) or the client app ID—**not** the API app ID - **Required permission = “Configured”** (placeholder) instead of the fully‑resolved string - Attaching such an extension to the flow yields 1003009 every time, even though the Function ran successfully. **Clean slate & rebinding attempts** - Deleted and re‑created extensions many times; waited between panels; changed names to force re‑hydration; tried both **Create new app registration** and **Select an existing app registration**. - Confirmed the flow works **without** extensions (user creation & Power Pages sign‑in OK). - Confirmed Function keys/host keys and correct URL with
- Verified portal “Code + Test” and Application Insights show successful invocations with expected event types.
Conclusion from attempts: The wizard in our CIAM tenant intermittently fails to render or persist the Resource application selection and ends up binding the extension to its auto‑created client app rather than our API app—producing an audience mismatch and 1003009 immediately after the Function returns 200.
Expected vs Actual
Expected (working tenant):
- API Authentication shows Resource application: CIAMprovingAPIclean (selectable)
- Summary shows:
- `Required app ID URI = api://ciamprovingy1.azurewebsites.net/8cd9257d-…-e36f` - `Required permission = Receive custom authentication extension HTTP requests` - User flow proceeds to Attribute Collection after the callback (no 1003009) **Actual (our tenant):** - Resource application selector **often missing** or selection **not persisted** - Summary shows **auto‑created client app** (e.g., *Extra001*) as Resource application and/or **`{appid}`** placeholder - “Required permission” frequently shows **Configured** - User flow fails with **AADSTS1100001 / 1003009** immediately after Function returns
- Summary shows:
Hypothesis
This looks like a CIAM tenant‑side wizard regression/caching defect where the Resource application binding is not surfaced or not applied. The extension is then saved without a correct Resource application audience, or with the client app set as the Resource—leading to token audience mismatch and 1003009.
What we need Microsoft to do
- Confirm the extension objects created in our tenant (latest failing one is fine) and verify which Resource application they are actually bound to.
- Validate that the extension’s resourceApplicationId is
8cd9257d-a7b6-4a76-aa7c-80e1560ee36f(our API app).- If the binding points to an auto‑created client app (e.g., Extra001), please correct it and confirm the fix.
- Investigate why the “Resource application” selector is intermittently not rendered/persisted in the API Authentication panel for our tenant; we have provided multiple screenshots where the control is missing and/or the
{appid}placeholder is shown on save. - Provide a supported workaround for creating the extension via Microsoft Graph that explicitly sets resourceApplicationId = 8cd9…e36f (we’re willing to use Graph if that’s the current recommended path for affected tenants).
- Confirm whether, under the new CIAM model, the only permission expected is the built‑in “Receive custom authentication extension HTTP requests”, and that no legacy scope selection is required (our UI no longer shows scope pickers).
- Validate that the extension’s resourceApplicationId is
Repro steps (minimal)
- Function App
ciamprovingy1(Windows Y1, Node v3) with HTTP triggerCIAMproofatPOST /api/ciam/proof—returns CIAM‑compliant JSON. - Create custom extension (Before) → Wizard → API Authentication.
- Observed: Resource application selector often missing; when present, selecting CIAMprovingAPIclean does not persist back to summary (summary shows client app /
{appid}placeholder). - Attach extension to
PPXMFlowand run sign‑up → Function executes 200 OK → CIAM fails with AADSTS1100001 / 1003009.
Attachments available
- Screenshots:
- API Authentication without Resource application selector
- Selection dialog listing CIAMprovingAPIclean among Enterprise applications
- Summary pages showing Resource application = Extra001 (client app) and
{appid}placeholders- Function logs showing successful invocation and event type
- Request Ids / Correlation Ids (see list above)
- Summary pages showing Resource application = Extra001 (client app) and
- Selection dialog listing CIAMprovingAPIclean among Enterprise applications
- API Authentication without Resource application selector
Current status
- Function endpoint is live and correct.
- User flow without extensions completes as expected.
- User flow with extension fails after the callback with 1003009 due to incorrect Resource application binding in the extension.
- We need Microsoft to review/repair the extension objects in our tenant or provide a Graph‑based creation path that binds
resourceApplicationIdto8cd9257d-a7b6-4a76-aa7c-80e1560ee36fexplicitly.
If you want, I can also include a short Graph payload you can paste into az rest or Graph Explorer that creates the extension with the correct resourceApplicationId so Support can reproduce and compare.Below is a ready‑to‑paste statement you can use in your Microsoft support ticket.
I’ve captured environment details, exact steps tried, timestamps, app IDs/names, observed errors, and the working hypothesis that your CIAM extension wizard is not consistently binding to the correct Resource application—resulting in AADSTS1100001 / 1003009 even though the Function executes successfully.
Issue summary
We are unable to complete a CIAM custom authentication extension (Before/After) for a working Azure Functions HTTP endpoint.
Despite the Function executing and returning a valid CIAM‑compliant response, the CIAM user flow fails immediately after the callback with:
AADSTS1100001: Non-retryable error has occurred.
Underlying error code: 1003009
Based on repeated, clean-room repros and screenshots, the CIAM extension wizard in our tenant intermittently fails to expose or honor the “Resource application” selector and/or binds the extension to the wrong application (client app) instead of our Resource API application, causing audience mismatch and the consistent 1003009 failure.
Environment
- Tenant (External ID / CIAM): IRSLOBBY – Tenant ID
8299aefb-503c-48f5-bc8c-293d6acdf888 - User flow:
PPXMFlow - Function App (Windows classic Consumption / Y1):
ciamprovingy1(Node ~24) - Function (v3 model):
CIAMproofat routePOST /api/ciam/proof - Function returns CIAM‑compliant schema:
{"version":"1.0.0","action":"Continue","userAttributes":[],"userDefinedClaims":[{"claimId":"echoEventType","value":"..."}]} - API (Resource) application intended for binding:
CIAMprovingAPIclean- App ID:
8cd9257d-a7b6-4a76-aa7c-80e1560ee36f- Application ID URI:
api://ciamprovingy1.azurewebsites.net/8cd9257d-a7b6-4a76-aa7c-80e1560ee36f- (Has a Service Principal; signInAudience set to multi‑tenant + MSA; exposes a simple “access” scope or, under new CIAM model, uses the built‑in “Receive custom authentication extension HTTP requests” binding.)
- Application ID URI:
- App ID:
What works (proven)
- The Function endpoint is reachable and executes successfully from CIAM:
- Logs (multiple times) show:
- `Request successfully matched the route 'api/ciam/proof'` - `AuthenticationScheme: WebJobsAuthLevel was successfully authenticated.` - `Executing 'Functions.CIAMproof' …` - **`[CIAMProof] event=microsoft.graph.authenticationEvent.attributeCollectionStart`** - `Executed 'Functions.CIAMproof' (Succeeded, Duration≈7–25ms)` - Manual `curl` POST to the function with a valid function/host key returns HTTP 200 and the expected CIAM JSON. - Function discovery is now stable (v3 structure: `/wwwroot/host.json` + `/wwwroot/CIAMproof/function.json,index.js`).
- Logs (multiple times) show:
Conclusion: The Function App is not the problem. The failure happens after we return 200—inside CIAM’s validation.
What fails (symptoms)
Immediately after the Function returns 200 OK, CIAM fails the step with AADSTS1100001 / 1003009.
Representative instances (UTC):
- 2026‑03‑15 20:14:05Z — Request Id
a17d9cb4-1854-43a1-9c36-917a095b0100, Correlation Id5d0d918b-2006-4fd7-b0a6-ad896cff9f94 - 2026‑03‑15 22:21:56Z — Request Id
9477a325-06ba-4c7d-a2b2-f5f8527f0100, Correlation Id82db1baa-9e80-4afc-b441-8af3516bb092 - 2026‑03‑15 22:29:24Z — Request Id
ab7b01bb-6aef-4a30-832a-da4957f90000, Correlation Id2841489d-9419-424f-ab04-00dc4ed5dd31 - 2026‑03‑16 00:31:28Z — Request Id
8cf4b6b5-85fd-4a50-8152-382ae7a40100, Correlation Id09256dcb-1e6c-44cb-8e15-db1d50823e6c - 2026‑03‑16 14:02:38Z — Request Id
093b5827-8467-42dc-820e-32b4b5530300, Correlation Id2155dfef-a5c5-4939-8357-ad86899e7ed8
Observation: These errors occur only when the extension is attached; user flow without the extension completes and creates the user successfully.
Attempts already made (chronology & highlights)
Function side
- Migrated off Flex Consumption (v4 model) to Windows classic Y1; rebuilt as Node v3 with
function.json+index.js.- Verified portal “Code + Test” and Application Insights show successful invocations with expected event types.
- Confirmed Function keys/host keys and correct URL with
?code=.
- Created **`CIAMprovingAPIclean`** as a clean API app. - Set **Application ID URI** to the Function hostname + appId. - Ensured Service Principal exists; signInAudience is multi‑tenant/MSA. - In newer CIAM UI, “Required permission: Receive custom authentication extension HTTP requests” is displayed (no legacy scope picker). **Service principal visibility & audience** - Ensured the **Resource application** SP appears in Enterprise applications (verified). - Confirmed visible `servicePrincipalNames` include both the GUID and the Application ID URI. **Extension creation – multiple rounds (Edge/Chrome/Firefox)** - Created **Before** extensions via “Create new app registration” **and** via “Select an existing app registration”. - Reproduced on fresh browser sessions (incl. Firefox just installed), new tabs, and with >5–8s hydration waits on each wizard panel. - **Consistent anomaly**: The **API Authentication** panel often **omits** the **“Resource application: Change”** block entirely; when it appears, selecting `CIAMprovingAPIclean` does not always persist back to the summary, which then shows: - **Resource application = a newly generated client app** (e.g., `Extra001`, `CIAMautobuild2`, `CIAMprovingy1Before`) - **Required app ID URI = `api://…/{appid}`** (placeholder) or the client app ID—**not** the API app ID - **Required permission = “Configured”** (placeholder) instead of the fully‑resolved string - Attaching such an extension to the flow yields 1003009 every time, even though the Function ran successfully. **Clean slate & rebinding attempts** - Deleted and re‑created extensions many times; waited between panels; changed names to force re‑hydration; tried both **Create new app registration** and **Select an existing app registration**. - Confirmed the flow works **without** extensions (user creation & Power Pages sign‑in OK). - Confirmed Function keys/host keys and correct URL with
- Verified portal “Code + Test” and Application Insights show successful invocations with expected event types.
Conclusion from attempts: The wizard in our CIAM tenant intermittently fails to render or persist the Resource application selection and ends up binding the extension to its auto‑created client app rather than our API app—producing an audience mismatch and 1003009 immediately after the Function returns 200.
Expected vs Actual
Expected (working tenant):
- API Authentication shows Resource application: CIAMprovingAPIclean (selectable)
- Summary shows:
- `Required app ID URI = api://ciamprovingy1.azurewebsites.net/8cd9257d-…-e36f` - `Required permission = Receive custom authentication extension HTTP requests` - User flow proceeds to Attribute Collection after the callback (no 1003009) **Actual (our tenant):** - Resource application selector **often missing** or selection **not persisted** - Summary shows **auto‑created client app** (e.g., *Extra001*) as Resource application and/or **`{appid}`** placeholder - “Required permission” frequently shows **Configured** - User flow fails with **AADSTS1100001 / 1003009** immediately after Function returns
- Summary shows:
Hypothesis
This looks like a CIAM tenant‑side wizard regression/caching defect where the Resource application binding is not surfaced or not applied. The extension is then saved without a correct Resource application audience, or with the client app set as the Resource—leading to token audience mismatch and 1003009.
What we need Microsoft to do
- Confirm the extension objects created in our tenant (latest failing one is fine) and verify which Resource application they are actually bound to.
- Validate that the extension’s resourceApplicationId is
8cd9257d-a7b6-4a76-aa7c-80e1560ee36f(our API app).- If the binding points to an auto‑created client app (e.g., Extra001), please correct it and confirm the fix.
- Investigate why the “Resource application” selector is intermittently not rendered/persisted in the API Authentication panel for our tenant; we have provided multiple screenshots where the control is missing and/or the
{appid}placeholder is shown on save. - Provide a supported workaround for creating the extension via Microsoft Graph that explicitly sets resourceApplicationId = 8cd9…e36f (we’re willing to use Graph if that’s the current recommended path for affected tenants).
- Confirm whether, under the new CIAM model, the only permission expected is the built‑in “Receive custom authentication extension HTTP requests”, and that no legacy scope selection is required (our UI no longer shows scope pickers).
- Validate that the extension’s resourceApplicationId is
Repro steps (minimal)
- Function App
ciamprovingy1(Windows Y1, Node v3) with HTTP triggerCIAMproofatPOST /api/ciam/proof—returns CIAM‑compliant JSON. - Create custom extension (Before) → Wizard → API Authentication.
- Observed: Resource application selector often missing; when present, selecting CIAMprovingAPIclean does not persist back to summary (summary shows client app /
{appid}placeholder). - Attach extension to
PPXMFlowand run sign‑up → Function executes 200 OK → CIAM fails with AADSTS1100001 / 1003009.
Attachments available
- Screenshots:
- API Authentication without Resource application selector
- Selection dialog listing CIAMprovingAPIclean among Enterprise applications
- Summary pages showing Resource application = Extra001 (client app) and
{appid}placeholders- Function logs showing successful invocation and event type
- Request Ids / Correlation Ids (see list above)
- Summary pages showing Resource application = Extra001 (client app) and
- Selection dialog listing CIAMprovingAPIclean among Enterprise applications
- API Authentication without Resource application selector
Current status
- Function endpoint is live and correct.
- User flow without extensions completes as expected.
- User flow with extension fails after the callback with 1003009 due to incorrect Resource application binding in the extension.
- We need Microsoft to review/repair the extension objects in our tenant or provide a Graph‑based creation path that binds
resourceApplicationIdto8cd9257d-a7b6-4a76-aa7c-80e1560ee36fexplicitly.
Microsoft Security | Microsoft Identity Manager
-
Richard Collins 21 Reputation points
2026-03-16T17:08:34.38+00:00 Trying more options as this is yet another blocker to provisioning a site which needs security tailored to a customers profile so needs to use customisations upon entry!
More trials and this time including the configuration via powershell / graph to avoid what appears to be the failing U.U.
Entra External ID (CIAM): Custom Authentication Extension binds without required permission (“Configured”), fails post‑callback with AADSTS1100001 / 1003009
Tenant / Environment
- Tenant name: IRSLOBBY (External ID / CIAM)
- Tenant ID:
8299aefb-503c-48f5-bc8c-293d6acdf888 - User flow:
PPXMFlow - Region: (same as tenant)
- Date/Time of latest failures (UTC): 2026‑03‑16T16:55:19Z and earlier
What we’re trying to do
Add a Custom Authentication Extension (Before / AttributeCollectionStart) that calls an Azure Function endpoint and returns a valid Continue payload so the flow proceeds to the Attribute Collection page.
Backend API (Resource application)
- App registration (API):
CIAMprovingAPIclean - App (client) ID:
8cd9257d-a7b6-4a76-aa7c-80e1560ee36f - Application ID URI (resourceId):
api://ciamprovingy1.azurewebsites.net/8cd9257d-a7b6-4a76-aa7c-80e1560ee36f - Service principal: present in Enterprise Applications
- Sign‑in audience: multi‑tenant/MSA
Azure Function (endpoint)
- App:
ciamprovingy1(Windows / classic Consumption Y1, Node.js v3) - Function:
CIAMproof, HTTP POST, route/api/ciam/proof - Response (CIAM‑compliant):
{ "version":"1.0.0","action":"Continue","userAttributes":[],
"userDefinedClaims":[{"claimId":"echoEventType","value":"microsoft.graph.authenticationEvent.attributeCollectionStart"}] }
- Runtime logs confirm execution and success, e.g.:
Executing 'Functions.CIAMproof' (Succeeded)… [CIAMProof] event=microsoft.graph.authenticationEvent.attributeCollectionStart
Target URL used in extension (masked):
https://ciamprovingy1.azurewebsites.net/api/ciam/proof?code=TRrK…IRJuA==(We will rotate the function key after the investigation.)The problem (symptom)
Immediately after the function returns 200 OK with a valid CIAM payload, the user flow fails with:
AADSTS1100001: Non-retryable error has occurred. Underlying error code: 1003009.Representative failures
- 2026‑03‑16T16:55:19Z — Request Id:
c71775b2-ae0c-465f-a29b-efb59b6e0300, Correlation Id:8f8ccb8e-39b2-43ff-803a-a9ac2b1536d3 - 2026‑03‑16T14:02:38Z — Request Id
093b5827-8467-42dc-820e-32b4b5530300, Correlation Id2155dfef-a5c5-4939-8357-ad86899e7ed8 - 2026‑03‑15 (multiple) with same pattern
What we already tried (chronology highlights)
Function correctness
- Rebuilt as Node v3 (function.json + index.js), verified discovery.
- Portal “Code + Test” and App Insights show the function runs and returns the expected JSON.
- cURL tests return HTTP 200 with the correct body.
- `CIAMprovingAPIclean` SP exists, correct Application ID URI. - Appears in Enterprise Apps and App registrations as expected. **Wizard creation attempts (Edge/Chrome/Firefox)** - The **API Authentication** step often **does not render a “Resource application” selector**, or if it appears, the selection sometimes **does not persist**. - Resulting extensions show **“Required permission: Configured”** and/or `{appid}` placeholders. - These extensions **always** fail with 1003009 post‑callback. **Graph creation (works, but UI still “Configured”)** - We created the extension via Graph with the documented derived type and shapes. Example used successfully (result **201 Created**): POST [https://graph.microsoft.com/v1.0/identity/customAuthenticationExtensions](https://graph.microsoft.com/v1.0/identity/customAuthenticationExtensions) Content-Type: application/json { "@odata.type": "#microsoft.graph.onAttributeCollectionStartCustomExtension", "displayName": "CIAMvGraph-Before", "description": "Created via Graph to bind to CIAMprovingAPIclean", "authenticationConfiguration": { "@odata.type": "#microsoft.graph.azureAdTokenAuthentication", "resourceId": "api://ciamprovingy1.azurewebsites.net/8cd9257d-a7b6-4a76-aa7c-80e1560ee36f" }, "endpointConfiguration": { "@odata.type": "#microsoft.graph.httpRequestEndpoint", "targetUrl": "[https://ciamprovingy1.azurewebsites.net/api/ciam/proof?code=TRrK…IRJuA=="](https://ciamprovingy1.azurewebsites.net/api/ciam/proof?code=TRrK%E2%80%A6IRJuA==%22) }, "clientConfiguration": { "timeoutInMilliseconds": 2000, "maximumRetries": 1 } } - **Created extension id:** `1854f8c4-f762-4eef-b658-15cbdec43be4` (AttributeCollectionStart). - In the portal, **Resource application shows correctly** (CIAMprovingAPIclean, App ID = `8cd9…e36f`) but **“Required permission” remains “Configured”**; there is **no visible client app** to assign the Graph app role to.
- Portal “Code + Test” and App Insights show the function runs and returns the expected JSON.
Expected vs Actual (UI / binding)
- Expected: API Authentication should display the fixed text “Receive custom authentication extension HTTP requests” (or equivalent), indicating the internal client is provisioned and the Graph app role has been granted.
- Actual: The portal consistently shows “Required permission: Configured”, and the user flow fails post‑callback with 1003009.
Hypothesis (what we suspect is wrong in the tenant)
The internal client application that CIAM uses to call our endpoint is not being provisioned and/or not granted the required Graph app role:
- Microsoft Graph Application role:
CustomAuthenticationExtension.Receive.Payload
Because this role is not applied to the extension’s client identity, CIAM can’t obtain a token to validate the callback (audience is correct; permission is missing), leading to AADSTS1100001 / 1003009 immediately after our function returns 200.
What we need Microsoft to do
- Verify/repair backend provisioning for Custom Authentication Extensions in tenant
8299aefb-503c-48f5-bc8c-293d6acdf888, specifically:- Ensure the extension client application is created/visible for our extension
1854f8c4-f762-4eef-b658-15cbdec43be4.- Ensure the client app is granted the Graph application role
CustomAuthenticationExtension.Receive.Payload(or its current equivalent in CIAM), so the portal’s API Authentication shows the fixed permission text (not “Configured”).
- Confirm that the portal wizard in this tenant is affected by the known Resource application/permission binding issue, where the selector doesn’t render or the binding isn’t persisted.
- Provide a tenant‑side remediation (or apply it) so newly created extensions bind correctly without manual Graph workarounds.
- Ensure the client app is granted the Graph application role
- Ensure the extension client application is created/visible for our extension
Attachments we can provide (on request)
- Screenshots showing:
- Function App logs (successful execution, 200 OK).
- CIAM wizard API Authentication panel missing the Resource selector or showing “Configured”.
- The Graph 201 Created response for
CIAMvGraph‑Beforewith the correct@odata.typeandresourceId.- Error pages with Request Id / Correlation Id listed above.
- App registrations / Enterprise apps listings (API app present; no client app surfaced).
- Error pages with Request Id / Correlation Id listed above.
- The Graph 201 Created response for
- CIAM wizard API Authentication panel missing the Resource selector or showing “Configured”.
- Function App logs (successful execution, 200 OK).
Contact / Next steps
- We can reproduce on demand and supply fresh Request/Correlation Ids within minutes.
- We will rotate the function key if required; please advise if you need a temporary test key.
If you want, I can also paste the exact JSON of the created extension (with the full
id) into the ticket once you’ve filed it, or draft a 1‑paragraph executive summary for the ticket header.Below is a ready‑to‑paste support ticket. I’ve kept it crisp, complete, and action‑oriented. You can submit it as is.
Title
Entra External ID (CIAM): Custom Authentication Extension binds without required permission (“Configured”), fails post‑callback with AADSTS1100001 / 1003009
Tenant / Environment
- Tenant name: IRSLOBBY (External ID / CIAM)
- Tenant ID:
8299aefb-503c-48f5-bc8c-293d6acdf888 - User flow:
PPXMFlow - Region: (same as tenant)
- Date/Time of latest failures (UTC): 2026‑03‑16T16:55:19Z and earlier
What we’re trying to do
Add a Custom Authentication Extension (Before / AttributeCollectionStart) that calls an Azure Function endpoint and returns a valid Continue payload so the flow proceeds to the Attribute Collection page.
Backend API (Resource application)
- App registration (API):
CIAMprovingAPIclean - App (client) ID:
8cd9257d-a7b6-4a76-aa7c-80e1560ee36f - Application ID URI (resourceId):
api://ciamprovingy1.azurewebsites.net/8cd9257d-a7b6-4a76-aa7c-80e1560ee36f - Service principal: present in Enterprise Applications
- Sign‑in audience: multi‑tenant/MSA
Azure Function (endpoint)
- App:
ciamprovingy1(Windows / classic Consumption Y1, Node.js v3) - Function:
CIAMproof, HTTP POST, route/api/ciam/proof - Response (CIAM‑compliant):
{ "version":"1.0.0","action":"Continue","userAttributes":[],
"userDefinedClaims":[{"claimId":"echoEventType","value":"microsoft.graph.authenticationEvent.attributeCollectionStart"}] }
- Runtime logs confirm execution and success, e.g.:
Executing 'Functions.CIAMproof' (Succeeded)… [CIAMProof] event=microsoft.graph.authenticationEvent.attributeCollectionStart
Target URL used in extension (masked):
https://ciamprovingy1.azurewebsites.net/api/ciam/proof?code=TRrK…IRJuA==
(We will rotate the function key after the investigation.)The problem (symptom)
Immediately after the function returns 200 OK with a valid CIAM payload, the user flow fails with:
AADSTS1100001: Non-retryable error has occurred. Underlying error code: 1003009.Representative failures
- 2026‑03‑16T16:55:19Z — Request Id:
c71775b2-ae0c-465f-a29b-efb59b6e0300, Correlation Id:8f8ccb8e-39b2-43ff-803a-a9ac2b1536d3 - 2026‑03‑16T14:02:38Z — Request Id
093b5827-8467-42dc-820e-32b4b5530300, Correlation Id2155dfef-a5c5-4939-8357-ad86899e7ed8 - 2026‑03‑15 (multiple) with same pattern
What we already tried (chronology highlights)
Function correctness
- Rebuilt as Node v3 (function.json + index.js), verified discovery.
- Portal “Code + Test” and App Insights show the function runs and returns the expected JSON.
- cURL tests return HTTP 200 with the correct body.
- `CIAMprovingAPIclean` SP exists, correct Application ID URI. - Appears in Enterprise Apps and App registrations as expected. **Wizard creation attempts (Edge/Chrome/Firefox)** - The **API Authentication** step often **does not render a “Resource application” selector**, or if it appears, the selection sometimes **does not persist**. - Resulting extensions show **“Required permission: Configured”** and/or `{appid}` placeholders. - These extensions **always** fail with 1003009 post‑callback. **Graph creation (works, but UI still “Configured”)** - We created the extension via Graph with the documented derived type and shapes. Example used successfully (result **201 Created**): POST [https://graph.microsoft.com/v1.0/identity/customAuthenticationExtensions](https://graph.microsoft.com/v1.0/identity/customAuthenticationExtensions) Content-Type: application/json { "@odata.type": "#microsoft.graph.onAttributeCollectionStartCustomExtension", "displayName": "CIAMvGraph-Before", "description": "Created via Graph to bind to CIAMprovingAPIclean", "authenticationConfiguration": { "@odata.type": "#microsoft.graph.azureAdTokenAuthentication", "resourceId": "api://ciamprovingy1.azurewebsites.net/8cd9257d-a7b6-4a76-aa7c-80e1560ee36f" }, "endpointConfiguration": { "@odata.type": "#microsoft.graph.httpRequestEndpoint", "targetUrl": "[https://ciamprovingy1.azurewebsites.net/api/ciam/proof?code=TRrK…IRJuA=="](https://ciamprovingy1.azurewebsites.net/api/ciam/proof?code=TRrK%E2%80%A6IRJuA==%22) }, "clientConfiguration": { "timeoutInMilliseconds": 2000, "maximumRetries": 1 } } - **Created extension id:** `1854f8c4-f762-4eef-b658-15cbdec43be4` (AttributeCollectionStart). - In the portal, **Resource application shows correctly** (CIAMprovingAPIclean, App ID = `8cd9…e36f`) but **“Required permission” remains “Configured”**; there is **no visible client app** to assign the Graph app role to.
- Portal “Code + Test” and App Insights show the function runs and returns the expected JSON.
Expected vs Actual (UI / binding)
- Expected: API Authentication should display the fixed text “Receive custom authentication extension HTTP requests” (or equivalent), indicating the internal client is provisioned and the Graph app role has been granted.
- Actual: The portal consistently shows “Required permission: Configured”, and the user flow fails post‑callback with 1003009.
Hypothesis (what we suspect is wrong in the tenant)
The internal client application that CIAM uses to call our endpoint is not being provisioned and/or not granted the required Graph app role:
- Microsoft Graph Application role:
CustomAuthenticationExtension.Receive.Payload
Because this role is not applied to the extension’s client identity, CIAM can’t obtain a token to validate the callback (audience is correct; permission is missing), leading to AADSTS1100001 / 1003009 immediately after our function returns 200.
What we need Microsoft to do
- Verify/repair backend provisioning for Custom Authentication Extensions in tenant
8299aefb-503c-48f5-bc8c-293d6acdf888, specifically:- Ensure the extension client application is created/visible for our extension
1854f8c4-f762-4eef-b658-15cbdec43be4.- Ensure the client app is granted the Graph application role
CustomAuthenticationExtension.Receive.Payload(or its current equivalent in CIAM), so the portal’s API Authentication shows the fixed permission text (not “Configured”).
- Confirm that the portal wizard in this tenant is affected by the known Resource application/permission binding issue, where the selector doesn’t render or the binding isn’t persisted.
- Provide a tenant‑side remediation (or apply it) so newly created extensions bind correctly without manual Graph workarounds.
- Ensure the client app is granted the Graph application role
- Ensure the extension client application is created/visible for our extension
Attachments we can provide (on request)
- Screenshots showing:
- Function App logs (successful execution, 200 OK).
- CIAM wizard API Authentication panel missing the Resource selector or showing “Configured”.
- The Graph 201 Created response for
CIAMvGraph‑Beforewith the correct@odata.typeandresourceId.- Error pages with Request Id / Correlation Id listed above.
- App registrations / Enterprise apps listings (API app present; no client app surfaced).
- Error pages with Request Id / Correlation Id listed above.
- The Graph 201 Created response for
- CIAM wizard API Authentication panel missing the Resource selector or showing “Configured”.
- Function App logs (successful execution, 200 OK).
-
Richard Collins 21 Reputation points
2026-03-17T03:24:23.5866667+00:00 Some progress.
Rebuilding the functions in c# and executed in the Premium plan does get them invoked but issues with surfacing email address and combining start/submit functions doesn't work.
I never got this far with node.js in Flex consumption and dynamic y1
Sign in to comment
Sign in to answer