> Sure, cookies are used for tracking, but they are also used for authentication, which is something that nearly every webapp needs to do.
What if we could move authentication or more specifically the state held in the client for authentication to some other mechanism? Could we pitch cookies? Could we make this switch without making it somehow possible for advertisers to switch to the new mechanism?
There's no reason to if you specifically block third-party cookies, which is what is being suggested (and what Axios muddies considerably by using "cookie" and "third-party cookie" interchangably).
Unless you're going to throw out local storage and custom request headers, getting rid of cookies isn't really going to do anything except make the same thing less secure (since you won't be able to benefit from the HttpOnly flag).
Authentication, notably OAuth, from all of the large major providers comes from a domain other than the site content domain. Blocking third party cookies indiscriminately will render you unable to log into facebook, google, twitter, or any microsoft service, or anything that uses those tokens.
The user clicks 'log in with google', their browser gets forwarded to whatever.google.com, the (now first party) cookie gets checked, then the user gets forwarded back to your site with the access token as a parameter in the GET request.
3rd-party cookies aren't actually intrinsic to OIDC auth flows. They might be used by some implementations under some flows, but they're not core to the spec.
Typically the user agent will redirect to a Google/etc login page where it'll have access to first-party cookies. Then will redirect back to the site which requested authentication, passing state in the query params. It's only when you get into using stuff like Okta as a delegated authentication service do you run into trouble with 3rd party cookies.
Edit: As an example, I just logged into Stackoverflow using Google as the authenticator, with umatrix blocking 3rd-party cookies. Worked without a hitch.
> Blocking third party cookies indiscriminately will render you unable to log into facebook, google, twitter, or any microsoft service, or anything that uses those tokens.
I block third party cookies indiscriminately, and I never had issues logging into Facebook, Google, Twitter, or any Microsoft service except for Microsoft Teams. This includes logging into third-party services using the Google login.
It could be done, but first-party cookies aren't really the issue. Most browsers have the option to disable third-party cookies, but many ad-supported sites throw a fit if you browse them that way. I think the goal is to introduce some alternative, then switch blocking third-party cookies to a default. Finally cookies could be a first-party only solution.
Most session providers use a session cookie and store all the required values on the server. Moving that to the client will require a lot of additional javascript. And will also make sure that browsing without javascript is definitely impossible. Not to think about the amount of additional security holes that would open.
Already exists. Custom HTTP Header with a JWT token for example. Also in the body of a post request can be the auth data. In the URL would also be possible but is a security risk due to e.g. browser history.
what if we remove the JS, and just had the web browser echo a defined string back to the server? if this token uniquely identified the session, we could safely store the data server-side, with minimal leakage to other sites and no need for code execution at all!
Install client SSL certificates for the websites that needs would be a start, or cookies die within 60 seconds unless a password has been entered on the site.
What if we could move authentication or more specifically the state held in the client for authentication to some other mechanism? Could we pitch cookies? Could we make this switch without making it somehow possible for advertisers to switch to the new mechanism?