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