MicrosoftMicrosoftThank you for this comprehensive post and detailed instructions. I'm currently implementing a similar setup in my organization and have encountered comparable challenges, including the one you highlighted regarding Foundry's missing Models API endpoint. I hope the Foundry team is prioritizing this, as maintaining a stub /v1/models endpoint in APIM for production instances with dynamic model deployments isn't sustainable.
While authenticating the APIM-to-Foundry path using Foundry keys or managed identities works adequately for now, I'm exploring whether the https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow could be leveraged with APIM as the intermediary. This approach might enable access to Foundry's project-level features—such as user management, quota enforcement, and cost attribution—for both Claude Desktop and programmatic usage.
I'd appreciate if you could explore this OAuth2.0 OBO flow option in a future post, assuming technical feasibility permits.
MicrosoftThanks — really appreciate the thoughtful feedback, and great to hear you’re implementing a similar pattern.
Completely agree on the /v1/models gap — the current stub approach in APIM works for static setups, but it definitely becomes fragile with dynamic model deployments. This is something I’m tracking closely as well.
The OBO flow idea is super interesting. I’ve been thinking along similar lines — using APIM as the policy enforcement point while preserving user context end-to-end could unlock:
The key question (as you pointed out) is how far we can push this given current Foundry APIs and identity surface area.
I’ll dig deeper into the OAuth2.0 OBO pattern with APIM + Foundry — if it proves viable, that’s definitely worth a follow-up post.
Would be great to stay in touch and compare notes as you progress.
