[OAUTH-WG] Re: OAuth Digest, Vol 208, Issue 19

[Chris Keogh <[e-mail]>]

Hi there all,

I'm dealing with a similar scenario that Tarun is highlighting and thought
I'd chime in to make it more concrete.

We have a mobile application and a web application that both use the same
IdP/AS. The mobile client (public+PKCE) uses long lived refresh tokens and
only requires the user to log in once (via the system browser) to retrieve
the access/refresh token combination. From this point on the user is
considered signed in to the mobile application, but the session at the IdP
will quickly expire (and the session/auth cookie in the system browser with
it).

We'd like to be able to embed web views within the mobile application that
are hosted by our web app without the user having to sign in again.

I've been thinking about using something along the lines of Identity
chaining or JWT authorization (with DPoP) to retrieve one time use short
lived access tokens that can be used by the mobile client to query an
endpoint which signs the user in and returns the contents of the IdP
session cookies to the mobile application, which then injects the cookies
into an embedded browser (not the system browser) which then loads the web
view which goes through the standard auth code flow.

As Tarun points out, it feels like there's a gap in the standards where
this kind of thing isn't really addressed. Potentially it's more of an OIDC
problem?


On Tue, 10 Feb 2026 at 03:54, <[e-mail]> wrote:

> Send OAuth mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
> Today's Topics:
>
>    1. Re: Feedback on ID-JAG same IdP prohibition - Application to
> Application Delegation
>       (Pieter Kasselman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 9 Feb 2026 14:53:14 +0000
> From: Pieter Kasselman <[e-mail]>
> Subject: [OAUTH-WG] Re: Feedback on ID-JAG same IdP prohibition -
>         Application to Application Delegation
> To: Tarun Nanduri <[e-mail]>
> Cc: Brian Campbell <bcampbell=[e-mail]>,
>         [e-mail]
> Message-ID:
>         <
> [e-mail]>
> Content-Type: multipart/alternative;
>         boundary="0000000000000d50df064a654dc1"
>
> Hi Tarun, for the original use case you described, you may want to consider
> the transaction token spec [1].
>
> It was specifically developed to allow authorization context, including
> user and workload/microservice identity information, to be passed between
> microservices within a domain, without having to pass around access tokens.
>
> Cheers
>
> Pieter
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/07/
>
> On Sun, Feb 8, 2026 at 8:02 AM Tarun Nanduri <[e-mail]>
> wrote:
>
> > Hi Pieter, Brian, Aaron, and the WG,
> >
> > Thanks for the feedback and for taking the time to look at this. I’ve
> been
> > thinking over the points about Section 8.3 and the general intent of
> ID-JAG.
> >
> > Stepping back from the specific spec for a second, it feels to me like we
> > have a bit of a gap in the OAuth/OIDC specifications. We’re essentially
> > looking for a standard way to do Directed Session Transfer, in
> environments
> > where shared cookies/SSO just aren't an option for security reasons.
> >
> > You pointed toward the Identity Chaining Across Domains draft as the
> > intended home for this, and I see the logic—since the AS in Domain A
> > generates the JWT grant, it handles the "identity proof" part of the
> > handover.
> >
> > But right now, if I want to move a user from App A to App B without a
> > fresh login, the options still feel a bit thin:
> >
> >    - Standard SSO is off the table because of the "no-shared-cookie"
> >    constraint.
> >    - RFC 8693 is a great building block, but it’s mostly used for
> >    service-to-service backend swaps. There isn't really a front-channel
> >    "profile" for this (as RFC863 sends back a usable token rather than an
> >    assertion).
> >    - Identity Chaining, as Brian mentioned, is explicitly a specification
> >    for cross-domain use.
> >
> >
> > It feels a bit ironic that the protocol makes "Cross-Domain" identity
> > transfers standardized via ID-JAG (as an OAuth native grant), but leaves
> > "Intra-Domain" delegation as a "roll-your-own" exercise. Without a
> standard
> > profile for this, people might just end up building non-standard hacks
> > which is exactly what we’re trying to avoid.
> >
> > I’m not trying to force a change to ID-JAG if the WG feels it’s the wrong
> > home, but I am curious:
> >
> >    - Do we think this "Directed Session transfer" pattern is a gap worth
> >    filling?
> >
> > It feels to me like there should be an "OAuth-native" way to do this that
> > has the right guardrails (audience binding, act claims, etc.) to make it
> > secure in a Zero Trust setup, but is as straightforward to implement as a
> > basic Auth Code grant. I’d love to hear if anyone else sees this gap, or
> if
> > there's a pattern I’m missing that doesn't involve a lot of custom "glue"
> > code.
> >
> > Best Regards,
> > Tarun Nanduri.
> >
> > On Thu, Feb 5, 2026 at 6:14 PM Pieter Kasselman <[e-mail]
> >
> > wrote:
> >
> >> Hi Tarun
> >>
> >> I agree with Brain and Aaron that your use case can likely be addressed
> >> by the Identity and Authorization Chaining Across Domains draft [1]. You
> >> could always profile it further if needed. Is there a reason you would
> not
> >> be able to use that draft?
> >>
> >> Cheers
> >>
> >> Pieter
> >>
> >> [1]
> https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/
> >>
> >> On Wed, Feb 4, 2026 at 9:31 PM Brian Campbell <bcampbell=
> >> [e-mail]> wrote:
> >>
> >>> Hi Tarun,
> >>>
> >>> As Aaron mentioned there are less tightly profiled variations of this
> >>> general flow, like oauth-identity-chaining
> >>> <https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/>
> >>> or rfc8693 <https://datatracker.ietf.org/doc/html/rfc8693> + rfc7523
> >>> <https://datatracker.ietf.org/doc/html/rfc7523> together directly,
> that
> >>> don't have the same constraint regarding the IDP not issuing access
> tokens
> >>> in response to an ID-JAG it issued itself. Perhaps that might meet your
> >>> needs? Although those are intended for cross domain as well. Honestly,
> much
> >>> of this seems like more than is needed for a same idp / same domain
> case.
> >>>
> >>> On Tue, Feb 3, 2026 at 8:13 PM Tarun Nanduri <[e-mail]>
> >>> wrote:
> >>>
> >>>> Dear Aaron,
> >>>>
> >>>> I am awaiting your feedback on this. To summarize,
> >>>>
> >>>> When an Identity Provider (IdP) does not support Single Sign-On (SSO)
> >>>> due to the nature of the systems involved, and a user needs to
> transfer
> >>>> their session to another application without re-logging in, I feel
> ID-JAG
> >>>> offers a secure and seamless solution, providing a smooth user
> experience.
> >>>>
> >>>> The RFC, as stated in previous emails, explicitly prohibits using the
> >>>> specification within the same IdP. Considering the zero-trust model
> >>>> typically applied within the same IdP, are we open to modifying the
> >>>> specification to allow its implementation within such environments?
> >>>>
> >>>> Best Regards,
> >>>> Tarun Nanduri.
> >>>>
> >>>> On Fri, Dec 5, 2025 at 8:46 AM Tarun Nanduri <[e-mail]
> >
> >>>> 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 <[e-mail]>
> >>>>> 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 <
> [e-mail]>
> >>>>>> 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 -- [e-mail]
> >>>> To unsubscribe send an email to [e-mail]
> >>>>
> >>>
> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> >>> privileged material for the sole use of the intended recipient(s). Any
> >>> review, use, distribution or disclosure by others is strictly
> prohibited.
> >>> If you have received this communication in error, please notify the
> sender
> >>> immediately by e-mail and delete the message and any file attachments
> from
> >>> your computer. Thank you.*
> >>> _______________________________________________
> >>> OAuth mailing list -- [e-mail]
> >>> To unsubscribe send an email to [e-mail]
> >>>
> >>
> -------------- next part --------------
> A message part incompatible with plain text digests has been removed ...
> Name: not available
> Type: text/html
> Size: 16713 bytes
> Desc: not available
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 208, Issue 19
> **************************************
>


-- 
Chris Keogh