Anthropic’s Claude Desktop ships with a shared-API-key model that’s a non-starter for regulated clients. Each user either shares a key — no per-user identity, no MFA, no audit trail — or you block the tool entirely. A newly published Microsoft architecture fixes this by routing Claude Desktop through Entra ID and Azure API Management, giving you per-user identity, Conditional Access, and centralized logging without writing a single line of backend code.
The governance gap Claude Desktop creates
Claude Desktop stores its API key in a local config file. Anyone with filesystem access can extract it. There is no native support for Entra ID, no way to enforce MFA, and no mechanism to audit who asked what. For an MSP with clients in finance, healthcare, or legal — sectors where AI desktop tools are increasingly requested — this is a blocker. You either say no, or you let it run unmanaged and hope nothing goes wrong.
The alternative has been building a custom proxy with authentication middleware, token exchange, and request logging. That is a backend project, not an afternoon configuration task. Most MSPs do not have the development bandwidth for it, so Claude Desktop stays unmanaged or gets blocked outright.
The architecture: Entra ID, APIM, no backend
Microsoft’s architecture — published on the Microsoft Developer Community blog — uses three existing Azure services in a chain that requires zero custom code:
1. Entra ID app registration. A single-tenant, public PKCE client (no client secret) with a redirect URI of http://127.0.0.1/callback under the Mobile and desktop applications platform. This is critical: registering under the Web platform requires a client secret and breaks the flow. The PowerShell script Microsoft provides is idempotent — safe to re-run.
2. Azure API Management as identity-aware reverse proxy. APIM sits between Claude Desktop and Microsoft Foundry. Its inbound policy validates the Entra ID token via validate-jwt, strips the user’s Authorization header, and injects the Foundry API key (or a managed-identity Bearer token) before forwarding the request. The Foundry key never leaves APIM.
3. Gateway SSO in Claude Desktop 1.5+. Claude Desktop connects in Gateway mode, authenticates interactively via browser PKCE, and forwards the ID token with each request. The configuration fields — gateway base URL, client ID, issuer URL — can be exported and pushed via Intune or Jamf.
No API keys ever touch user machines; the Foundry key resides only in APIM — or is eliminated entirely with managed identity.
Push config via Intune, same MDM you already use
Once the Azure side is configured — roughly an afternoon of portal work and one PowerShell script — the Claude Desktop client configuration is a static JSON blob. Export it as a .mobileconfig for macOS or a .reg for Windows, and push it through the same Intune or Jamf pipeline you already use for Wi-Fi profiles and compliance policies. No separate deployment tool, no user interaction beyond the first sign-in.
Revocation is equally straightforward: disable the Entra ID app registration, and every Claude Desktop instance behind it stops working. No scrambling to rotate a shared API key across dozens of machines.
Where existing Claude Enterprise SSO fits
If you already have Claude Desktop tied to your enterprise tenant through Entra SSO, you are halfway there. That controls who can sign in, applies MFA and Conditional Access, and gives you normal joiner/mover/leaver control. The architecture above is the next layer: it controls how model traffic leaves the workstation.
The practical distinction is important. Entra SSO for the Claude account does not automatically mean every model request is forced through your managed Azure gateway. For that, Claude Desktop needs to use Gateway mode, send an Entra-issued token to APIM, and APIM needs to reject anything that is not that valid JWT. If a user can point the client at a personal API key or a different endpoint, your SSO policy did not govern the traffic path.
Two checks matter before calling this governed. First, decide how quickly revoked or risky sessions should die. APIM validates tokens statelessly, so tune Conditional Access sign-in frequency and token lifetime expectations; if you need near-real-time revocation, plan for CAE-aware handling rather than assuming APIM behaves like Exchange or SharePoint. Second, treat the Intune or Jamf-pushed client config as non-secret metadata only. Locking the file helps with hygiene, but the real control is structural: no credentials in the config, no APIM subscription-key path, and no backend access unless the request carries the expected Entra token.
SSO answers who can open Claude. The gateway pattern answers whether every request is forced through your policy boundary.
What to check before deploying
There are a few traps in the setup that the Microsoft guide calls out explicitly:
- Platform registration matters. Register the Entra app under Mobile and desktop applications, not Web. A Web registration requires a client secret and produces 401 errors later, and the platform type cannot be changed — you must recreate the app.
- Issuer URL must end at /v2.0. Claude Desktop’s OIDC discovery will 404 if you paste the full metadata URL. The issuer field should be
https://login.microsoftonline.com/{tenant-id}/v2.0— nothing after. - Subscription required must be off. On the APIM API settings, uncheck “Subscription required.” The Entra ID token is the only credential; an APIM subscription key layered on top breaks authentication.
- Model discovery is off by default. Foundry’s /anthropic surface does not implement /v1/models. Either turn discovery off and set the model ID manually, or stub the endpoint with an APIM policy that returns a static JSON model list.
Why this matters now
Clients in regulated industries are asking for sanctioned AI desktop tools. They see Copilot in their M365 tenant, they hear about Claude from peers, and they want a governed path — not a policy of “just don’t install it.” This architecture gives MSPs that path using services they likely already have: Entra ID for identity, Intune for config push, and APIM if they run any Azure API workloads.
The setup is not zero-effort, but it is zero-code. That distinction matters when your capacity for custom development is spoken for by client projects and break-fix. An afternoon of portal configuration and one PowerShell script gets you per-user identity, Conditional Access, and an audit trail for Claude Desktop usage — the same controls your clients already expect for email, files, and every other sanctioned application.
