51–60 of 118 posts
I prefer using cookies, but most SPAs actually use JWTs.
Cookies and JWTs are not alternatives to each other. You can store a JWT in a cookie.
Cookies suck. The interface is beyond terrible, they were never scoped properly, and they don't have to be used. Browser storage (sessionStorage, localStorage) is perfectly valid for storing an authentication token.
No, it is not. And I hope I never end up using any application developed this way. Tokens stored in those storages you mention can be read by any javascript code, even third party. That doesn't happen with http-only cookies. Be careful with what you recommend publicly, as others might end up assuming this is fine, when it is clearly not.
Slack [0] has entered the chat.
Jira [1] has entered that chat.
I could go on but I don't need to. Many web applications that people use store an unnecessarily obnoxious amount of data locally. I can only imagine how much of that is used just once or possibly even never (like images in settings windows that were never accessed).
[0]: On one instance of Firefox on one computer, app.slack.com has stored 1.9GB. On another instance of Firefox on another computer, app.slack.com has stored about 633KB. On a third instance of Firefox on yet another computer, app.slack.com has stored about 600MB.
[1]: Jira doesn't load _at all_ if you've got any secure settings enabled (like... no CORS and no cross-domain cookies and no cross-domain XHRs and ... the list goes on). So Jira loads in an incognito window in a VM. But suffice to say that its local storage is even more _fucking obnoxious_.
> Tokens stored in those storages you mention can be read by any javascript code, even third party.
I don't doubt you. But I am not a javascript developer. I'd like it if you could link to some demonstrations of how that can be abused.
SPAs as in the UI/UX concept certainly not. SPAs as in “browser-based standalone applications that do cross-site authentication and API calls in the context of a modern identity and SSO architectures” – yes. Has the latter ever been a definition of "SPA"? One would have thought the acronym "single page application" to have been fairly precise...
What the article completely ignores, is the fact, that building cross site apps has been next to impossible for a long time. Since you can't contact a server who doesn't explicitly allows connections via CORS, your browser based app doomed. And I write this as someone who would love to build apps all day with web technologies.
I don't quite get what you mean. If the cross-origin server (to your app) wants to be consumed then it will respond with the correct headers. And if the server is under your control then you can configure it so.
To clarify I have nothing against actual web applications like an image editor or a game. However a wiki (I don't appreciate Notion), an online shop or a damned blog should not be one. I want my history, link copying, bookmarking, middle-clicks and Ctrl/Cmd-clicks to work as intended.
Earlier quoted context omitted.
They can't be read BUT the browser will send the cookie with every request. If you have an XSS, it is game over. The attacker can just send requests from your browser. Slightly less convenient. You are merely taking away the convenience of the attacker doing the attack manually on his own browser, which he probably doesn't want to do anyways. If he can inject js into your site, he will make your browser send the requ…
A good option is doing both. Store a security token in localStorage and additionally store a secure signature for it in a secure, HTTP-only cookie. On your backend, verify validity of both the token and its additional signature contained in the cookie.
[1] https://solidproject.org/ [2] https://github.com/inrupt/solid-client-authn-js
What the article completely ignores, is the fact, that building cross site apps has been next to impossible for a long time. Since you can't contact a server who doesn't explicitly allows connections via CORS, your browser based app doomed. And I write this as someone who would love to build apps all day with web technologies.
I don't quite get what you mean. If the cross-origin server (to your app) wants to be consumed then it will respond with the correct headers. And if the server is under your control then you can configure it so.
So take for example a WebDAV server. In theory, you could build a web based app, that can access any WebDAV server out there on the internet. In practice, that WebDAV server requires a special CORS configuration in order to be accessible via a browser from a different origin. Any other normal desktop app doesn't care about CORS and can access any server it has credentials for, no matter what configuration it has.
Earlier quoted context omitted.
Normal cookies are JS-accessible, but HTTP-only cookies should not be: "A cookie with the HttpOnly attribute is inaccessible to the JavaScript Document.cookie API; it is sent only to the server." https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#re...
Ah thanks! This is new to me. That is indeed a concern, but probably can be worked around, e.g. by proxying requests to third party domains through the same Domain.
If the demands of the developers out pace the demands of their users AND those demands primarily determine product design decisions the product is not all designed to benefit the user despite developers pleadings to the contrary. That is a very pronounced example of bias.