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

[Karl McGuinness <[e-mail]>]

@Chris, I think this topic might be more relevant to the OpenID Connect A/B
working group (https://openid.net/wg/connect/) as it appears to be a SSO
use case.  The OpenID Native SSO spec (
https://openid.net/specs/openid-connect-native-sso-1_0.html) supports 1
type of flow and vendors such as Okta support Mobile to Web SSO
https://developer.okta.com/docs/guides/native-to-web-sso/main/ using
proprietary mechanism.  There are a lot of security considerations/caveats
with this type of flow that would be best answered in the OIDC WG.

-Karl

On Mon, Feb 9, 2026 at 1:17 PM Chris Keogh <[e-mail]>
wrote:

> 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
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>