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