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

[Chris Keogh <[e-mail]>]

No worries Karl, I thought as much but thought I'd pipe up anyway.

Thanks 🙏🏼

On Tue, 10 Feb 2026 at 13:21, Karl McGuinness <[e-mail]> wrote:

> @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]
>>
>

-- 
Chris Keogh