Subject: [OAUTH-WG] Full Third-Party Cookie Blocking

From: Dominick Baier <[email-masked]>
Date: Wed, 25 Mar 2020 06:55:20 -0700

This

https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/

Really means that “modern” SPAs based on a combination of OIDC and OAuth
will not work anymore

both

* silent-renew for access token management
* OIDC JS session notifications

Will not work anymore. Or don’t work anymore already today - e.g. in Brave.

This means SPAs would need to be forced to do refresh tokens - and there is
no solution right now for session notifications.

Maybe the browser apps BCP / OAuth 2.1 should strictly advice against the
“browser apps without a back-end” scenario and promote the BFF style
architecture instead.

Cheers
———
Dominick Baier

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 25 Mar 2020 19:07:29 +0100

> On 25. Mar 2020, at 14:55, Dominick Baier <[email-masked]> wrote:
> 
> This
> 
> Really means that “modern” SPAs based on a combination of OIDC and OAuth will not work anymore
> 
> both
> 
> This means SPAs would need to be forced to do refresh tokens - and there is no solution right now for session notifications.
> 
> Maybe the browser apps BCP / OAuth 2.1 should strictly advice against the “browser apps without a back-end” scenario and promote the BFF style architecture instead.

Sound reasonable to me. 

> 
> Cheers 
> ———
> Dominick Baier
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: David Waite <[email-masked]>
Date: Wed, 25 Mar 2020 12:38:04 -0600

More specifically, SSO will not work anymore without either:
- prompting the user (via Storage Access API)
- using explicit front-channel mechanisms (popups and redirects)
- using back-channel mechanisms (refresh tokens and some backchannel logout infrastructure)

(FWIW, I proposed a back-channel session management mechanism which would work for SPA apps under Connect, https://bitbucket.org/openid/connect/src/default/distributed-token-validity-api.txt)

In my experience, the vast majority of apps only care about SSO from a user experience perspective, and don’t want synchronized session management. Many which do want session management are hosted _mostly_ under one origin since the organization is trying to hide that they are disparate applications - but many have exceptions, such as *.google.com and YouTube.com

-DW

> On Mar 25, 2020, at 7:55 AM, Dominick Baier <[email-masked]> wrote:
> 
> This
> 
> https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ <https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>