| ▲ | mu53 4 days ago |
| Cookies are an antiquated technology. One of the first introduced while the web was still young in the 90s, and they have had a few iterations of bad ideas. They are the only place to store opaque tokens, so you gotta use them for auth. |
|
| ▲ | vbezhenar 4 days ago | parent [-] |
| They are not the only place to store tokens. You can store tokens with localStorage for JS-heavy website, in fact plenty of websites do that. It's not as secure, but acceptable. Another alternative is to "store" token in URL, it was widely used in Java for some reason (jsessionid parameter). |
| |
| ▲ | lknuth 4 days ago | parent [-] | | To expand on the "not as secure" comment: local storage is accessible to every JS that runs in the context of the page. This includes anything loaded into the page via <script src=""/> like tracking or cookie consent services. | | |
| ▲ | brabel 4 days ago | parent | next [-] | | And I feel like it's important to expand on the fact that Cookies are visible to JS by default as well, except if the Cookie has the `HttpOnly` attribute set. Obviously, for auth, you absolutely want the session cookie to have both the `Secure` and `HttpOnly` attributes. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#bl... | |
| ▲ | vbezhenar a day ago | parent | prev [-] | | Scripts can do almost everything, for example replace the whole page with login page identical to the real and send entered password somewhere. Leaking session identifier is bad, but it's not as severe compared to other things scripts can do. | | |
| ▲ | lknuth 20 hours ago | parent [-] | | True, but your example is very targeted at a specific page. With local storage, you can have a simple short function that works everywhere and just sends everything back to your server. No need to specialize, works everywhere. |
|
|
|
