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

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 <dbaier@leastprivilege.com> 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/>
> 
> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>