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 <[email protected]> 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 <[email protected]> > 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, <[email protected]> wrote: >> >>> Send OAuth mailing list submissions to >>> [email protected] >>> >>> To subscribe or unsubscribe via email, send a message with subject or >>> body 'help' to >>> [email protected] >>> >>> You can reach the person managing the list at >>> [email protected] >>> >>> 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 <[email protected]> >>> Subject: [OAUTH-WG] Re: Feedback on ID-JAG same IdP prohibition - >>> Application to Application Delegation >>> To: Tarun Nanduri <[email protected]> >>> Cc: Brian Campbell <[email protected]>, >>> [email protected] >>> Message-ID: >>> < >>> caltwoa1kwhq8dibta9j52gcgqhnhqgel+owfjy9sjl_dpiq...@mail.gmail.com> >>> 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 <[email protected]> >>> 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 >>> <[email protected]> >>> > 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= >>> >> [email protected]> 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 < >>> [email protected]> >>> >>> 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 < >>> [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] >>> >>>> >>> >>> >>> >>> *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 -- [email protected] >>> >>> To unsubscribe send an email to [email protected] >>> >>> >>> >> >>> -------------- 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 -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>> >>> ------------------------------ >>> >>> End of OAuth Digest, Vol 208, Issue 19 >>> ************************************** >>> >> >> >> -- >> Chris Keogh >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > -- Chris Keogh
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
