And the latter is not even true unless I missed something significant. It's just lazy implementations thereof that are dead. Having developed SPAs for much of my career, I did plenty of cross-site login and work never realizing third party cookies were even an option. I just figured they were bad practice and that oauth2, understanding the limitations of web frontend oauth2 security (e.g. can't really do a full authenticated client without a backend to keep secret the client secret), and using proper CORS was the right way to do it. I think that's the way forward with the removal of third party cookies, is it not?

I guess I'm more surprised that somebody was using third party cookies for non-tracking purposes than I am surprised they're being removed.

> Some people recommend replacing silent renew with refresh tokens. This is dangerous advice – even if your token service has implemented countermeasures.

If I follow the link the author is clearly talking about public clients, which are always going to have significant security limitations. Somewhere else on the site he mentions BFF (backend for frontend) architecture as a mitigation. Which I kinda thought was the whole point of confidential vs public oauth2. The spec is super clear that public is less secure which is just the nature of security; if you have to ship a secret to someone who shouldn't know it, but they need to use it, you're kinda out of luck.

I think I'm picking up that the author's definition of SPA is also assuming no back-end, in which case many of the security points make a lot more sense. But even if you just throw out a secure authenticating proxy, which can be done with very little code and a few off-the-shelf and OSS products, you're back in business and more secure than ever.

Sounds like JAM stack to me

If I can trust 2018 OAuth-as-a-service vendor literature, it seems popular to signify "use grant flow X because your app has no backend."