Published app fails to retrieve SharePoint data — AADSTS50158 (Conditional Access step-up not completed)

[markus-tobler]

Summary

A Microsoft Managed App that reads a SharePoint Online list works correctly in local development (ms app dev), but the same data-source call fails once the app is published/deployed and accessed via play.managedapps.cloud.microsoft. The APIM/APIHub call to the SharePoint connector returns interaction_required (AADSTS50158), indicating a Conditional Access claims challenge that was never satisfied for the token used by the published runtime.

Environment

• Product: Microsoft Managed Apps (@microsoft/managed-apps-cli, "Cowork" app runtime)
• Host: https://play.managedapps.cloud.microsoft/
• Data source: SharePoint Online (Shared connector shared_sharepointonline), table binding to a SharePoint list ("AI Use Cases")
• Local dev: works — ms app dev, same tenant, same user, same data source binding
• Published app: fails consistently with the error below
• Tenant: isolutionsch.sharepoint.com tenant (Entra tenant id a6bbab92-053e-490b-bd7e-5cd03763b746)

Repro steps

1. Create an app with ms app create, add a SharePoint Online table data source (ms app add data-source --api-id shared_sharepointonline --as table), bind to list "AI Use Cases".
2. Verify data loads correctly with ms app dev (local dev works fine).
3. Deploy the app with ms app deploy.
4. Open the published app via ms app play / play.managedapps.cloud.microsoft.
5. Observe the page that fetches list items fails to load data.

Expected behavior

The published app successfully retrieves SharePoint list items, same as in local dev.

Actual behavior

The browser network trace shows the following failing request:

GET https://8d74cbe1-1694-e06b-9bf4-7288dbff2d46.10.common.europe002.azure-apihub.net/apim/sharepointonline/shared-sharepointonl-40490a90-2c30-4d19-a9a1-747639ff0a39/datasets/https%3A%2F%2Fisolutionsch.sharepoint.com%2Fsites%2F006753/tables/AI%20Use%20Cases/items
Referer: https://play.managedapps.cloud.microsoft/
Headers of note: x-ms-client-app-id: 23c4a1e5-8e09-453b-a0ac-7751f8c28cdb
                 x-ms-protocol-semantics: cdp
Authorization: Bearer <redacted JWT — aud=https://apihub.azure.com, appid=3e62f81e-590b-425b-9531-cad6683656cf, scp=Runtime.All>

Response body:

{
  "error": "interaction_required",
  "error_description": "AADSTS50158: External security challenge not satisfied. User will be redirected to another page or authentication provider to satisfy additional authentication challenges.",
  "error_codes": [50158],
  "suberror": "basic_action",
  "claims": "{\"access_token\":{\"capolids\":{\"essential\":true,\"values\":[\"88a19af6-da15-4acc-815a-0749adcbde19\",\"7bcdfcc7-8039-4fa0-9e78-c349b103de2b\",\"33f59b3d-d9cf-4023-8b55-8a29a1664495\"]}}}",
  "trace_id": "ba8756e7-4441-4c07-8d74-1233e9d06000",
  "correlation_id": "e60f356a-e692-44af-ab13-1e8e048d9e2f",
  "timestamp": "2026-09-23 08:02:31Z"
}

Hypothesis / suspected root cause

Local dev (ms app dev) obtains its access token through a full interactive browser sign-in, which is able to satisfy Conditional Access step-up requirements (the capolids in the claims challenge). The published app runtime, embedded in the play.managedapps.cloud.microsoft host, appears to acquire/reuse a token silently and does not resubmit the token request with the returned claims parameter to trigger the required step-up authentication (e.g., an interactive prompt/redirect for the additional CA challenge). As a result, every data call from the published app fails with interaction_required, even though the exact same user/tenant/data source works fine in local dev.

This looks like it needs a fix in the published-app auth/token-acquisition path (either surfacing an interactive re-auth prompt within the host iframe, or forwarding the claims challenge on retry) rather than being an app-configuration issue — the CA policy and user are the same across both dev and published, only the runtime differs.

Impact

Any published Managed App whose data source is protected by a Conditional Access policy requiring step-up authentication (device compliance, MFA, etc.) is unable to retrieve data at all — this appears to fully block the connector for affected tenants/users, though it works fine in local dev, so it may not be caught during development.

Additional notes

• Full name/UPN and the bearer JWT have been redacted from this report before sharing externally.
• Happy to provide the full HAR/network trace or additional repro details on request via a private channel.