Plans for Microsoft Entra ID on-behalf-of (RFC 7523 jwt-bearer) in addition to RFC 8693 token exchange?

[maciejstepniak]

Hi team, thanks for the RFC 8693 token exchange in v1.0.6 (PR #5224).

I want to use it with Microsoft Entra ID, but it does not fit. In v1.0.6 the grant is token-exchange and subject_token_source only accepts inbound_user_jwt. Entra's OBO flow is different: it uses the jwt-bearer grant (RFC 7523) with requested_token_use=on_behalf_of, and the assertion must be a token issued by Entra itself. So Entra will not accept a ContextForge-issued JWT.

Two questions:

1. Do you plan to support the Entra OBO variant (jwt-bearer grant)? If yes, any rough timeline?
2. Would you consider a subject_token_source option that passes through the original IdP token, instead of only the ContextForge JWT?
   Epic [EPIC][SECURITY]: OAuth 2.0 Token Exchange (RFC 8693) — User Delegation for Virtual Servers #3385 does not mention Entra, so we would like to know if this is on the roadmap.

For reference, Agentgateway recently added exactly this (an Entra OBO mode: the jwt-bearer grant with requested_token_use=on_behalf_of), so it looks feasible (https://agentgateway.dev/blog/2026-07-12-agentgateway-token-exchange-jwt-assertion-entra-obo/).

Thanks!

[maciejstepniak]

@jonpspri - friendly bump, with some context I found since posting.

To be precise about where this sits: #5885 covers the inbound direction (gateway trusts an Entra-issued token, with Entra-specific handling for group overage and uti). My question is about the outbound direction in #3385 — the gateway acquiring an upstream token. On Entra those aren't the same flow: OBO needs the jwt-bearer grant with requested_token_use=on_behalf_of and an Entra-issued assertion, not the RFC 8693 token-exchange grant with a ContextForge-issued JWT.

Two yes/no questions, purely about status:

1. Is Entra's OBO variant in scope for [EPIC][SECURITY]: OAuth 2.0 Token Exchange (RFC 8693) — User Delegation for Virtual Servers #3385, or explicitly out of scope?
2. Is a subject_token_source option that passes the original IdP token through (instead of the ContextForge-issued JWT) on the roadmap at all?

Even a "not planned" would help — it tells me whether to wait or work around it on our side.