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

[David Waite]

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  wrote:
> 
> 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
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

> On 25. Mar 2020, at 14:55, Dominick Baier  wrote:
> 
> 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.

Sound reasonable to me. 

> 
> Cheers 
> ———
> Dominick Baier
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Full Third-Party Cookie Blocking

[Dominick Baier]

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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth