copying Oauth WG, apologies for another reply over! On Fri, Dec 5, 2025 at 8:46 AM Tarun Nanduri <[email protected]> wrote:
> Hi Aaron, > > Thanks for the response, and pointing me to the Identity Chaining draft. > However, after looking at it, I don't think it applies to the use-case I > shared above (please feel free to correct here). It looks like it's > designed for cross-domain scenarios* whereas the use-case I shared above > has*, > > - Both the clients are in same trust domain > - We have single authorization server (it's the IdP too) > > The challenge we are trying to solve is, > > - Client A needs to transfer user session to client B > - WITHOUT Client A sharing its access token with client B (security > risk due to token exposure, invalid audience, unnecessary privileges etc.) > - Both clients trust the same IdP > > This is why we're intending to use RFC8693, but it still requires client A > to send access token (after token exchange) to client B which creates > exposure we're trying to avoid. The ID-JAG pattern (cryptographic proof of > identity, not a usable token) would be perfect, except the prohibition > defined in section 8.3 of Identity Assertion draft: > 8.3. > <https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#section-8.3>Cross-Domain > Use > <https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#name-cross-domain-use> > > This specification is intended for cross-domain uses where the Client, > Resource App, and Identity Provider are all in different trust domains. In > particular, the Identity Provider MUST NOT issue access tokens in > response to an ID-JAG it issued itself. Doing so could lead to > unintentional broadening of the scope of authorization. > My question remains, Can the section 8.3 prohibition be satisfied with > enough security controls (scope validation, replay prevention etc.) for > same IdP scenarios, or is it a hard limitation? > > Thanks and Regards, > Tarun Nanduri. > > > On Fri, Dec 5, 2025 at 1:53 AM Aaron Parecki <[email protected]> wrote: > >> Hi Tarun, >> >> It sounds like what you are looking for is the parent draft of this >> draft, Identity and Authorization Chaining Across Domains: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/ >> >> The document that defines the ID-JAG, Identity Assertion Authorization >> Grant, is a special case of Identity Chaining where both the client and >> resource have a pre-existing relationship with the same IdP. So I don't >> view it as a limitation, it's actually an optimization when there is a >> common IdP. The Identity Chaining draft is the same as this draft except it >> doesn't specify the input token format or the reason why the client and >> resource trust the cross-domain JWT issuer. >> >> Aaron >> >> >> >> On Mon, Dec 1, 2025 at 8:11 AM Tarun Nanduri <[email protected]> >> wrote: >> >>> Dear OAuth Working Group & Aaron, >>> >>> I would like to provide feedback on the OAuth Identity Assertion >>> Authorization Grant (ID-JAG) specification, specifically regarding >>> the prohibition against same-IdP usage. >>> >>> Use Case: >>> >>> In microservices architectures using the same IdP, there is a >>> legitimate need for service-to-service identity delegation WITHOUT >>> sharing access tokens directly: >>> >>> - Application A has a user-scoped token >>> - Application A needs to invoke Application B on behalf of user >>> - Sharing Token A with Application B creates security risks: >>> * Token exposure between services >>> * Replay attacks >>> * Over-privileged access >>> * Audience mismatch >>> >>> The Gap: >>> >>> ID-JAG's assertion pattern solves this perfectly: >>> - Application A creates a cryptographic identity assertion >>> - Assertion is audience-bound to Application B >>> - Application B exchanges assertion for its own token >>> - No credential sharing between services >>> >>> However, the same-IdP prohibition prevents this legitimate use case. >>> >>> Suggestion: >>> >>> Consider either: >>> 1. Removing the same-IdP prohibition with appropriate security guidance >>> 2. Adding an exception for service-to-service delegation scenarios >>> 3. Providing guidance on how to achieve this pattern within the same IdP >>> >>> RFC 8693 (Token Exchange) doesn't fully address this use case as it >>> requires sending the actual token (subject_token), which is what we're >>> trying to avoid. >>> >>> Security Considerations: >>> >>> With zero-trust validation, same-IdP assertions can be just as secure >>> as cross-IdP: >>> - Validate assertion issuer is authorized >>> - Apply fresh authorization policy evaluation >>> - Enforce audience restrictions >>> - Use short-lived assertions >>> - Implement scope intersection, not broadening >>> >>> Would appreciate the working group's consideration of this use case. >>> >>> Best regards, >>> Tarun Nanduri. >>> >>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
