4 ms·

JWT refresh tokens are equivalent to passwords. (they are active for days at a time). I do not know of many web apps that store passwords in browser storage.

JWT refresh tokens are equivalent to passwords. (they are active for days at a time). I do not know of many web apps that store passwords in browser storage. Unlike passwords, JWT refresh tokens are created programmatically (not entered by user interactively). Perhaps,I am just missing a link, but I though browsers do not allow an application to programmatically store passwords securely

penagwin 8y ago
JWT tokens, and any session tokens are used for authentication, like a password. The issue is that people don't want to entire a password every single time they want to send a request that requires authentication. Imagine google/facebook/etc. prompting you for a password every time you click a link. That's what it would be like if browsers couldn't store session tokens. Typically the matching hostname can view local data/cookies though (along with any extensions you have that have access to it - which is most of them). That's why you shouldn't ever copy/paste stuff into the console of a website, it lets people extract your session.
api_or_ipa 8y ago
If you don't persist JWT in localStorage or sessionStorage, how would you handle page reloads? You'd have to rely on a session cookie and get a new JWT from your auth service. You'd solve XSS but get CSRF. Storing a JWT in localstore isn't the same as storing a password in plain text. JWTs are indeed non-revocable, but they are also non-durable (ours expire after 24 hours) and cannot be renewed without a refreshToken. Most people also do not rely on JWTs to write important information (like password reset) because there are more secure alternatives for these specific use cases. As an aside, if someone gets script access to your SPA, you're already very far up shit creek. If your user types in any sensitive information like a password to login you've lost the war. Securing the JWT is the very least of your concerns at that point.
geofft 8y ago
There are two important attributes of a password: they're (often) human-memorable and prone to reuse / inexact reuse on other sites, and they're a long-term authentication token. JWT refresh tokens have the second attribute. But so are many other things, like regular old cookies that don't expire for weeks or months, which browsers store on a regular basis. If you're logged into HN you have one of these. While the HN cookie is HttpOnly, this isn't really putting it in more-secure storage: an XSS attack against HN can just issue whatever API requests to HN it wants, even though it can't easily walk off with a copy of the cookie.

penagwin 8y ago

JWT tokens, and any session tokens are used for authentication, like a password. The issue is that people don't want to entire a password every single time they want to send a request that requires authentication. Imagine google/facebook/etc. prompting you for a password every time you click a link. That's what it would be like if browsers couldn't store session tokens. Typically the matching hostname can view local data/cookies though (along with any extensions you have that have access to it - which is most of them). That's why you shouldn't ever copy/paste stuff into the console of a website, it lets people extract your session.

api_or_ipa 8y ago

If you don't persist JWT in localStorage or sessionStorage, how would you handle page reloads? You'd have to rely on a session cookie and get a new JWT from your auth service. You'd solve XSS but get CSRF. Storing a JWT in localstore isn't the same as storing a password in plain text. JWTs are indeed non-revocable, but they are also non-durable (ours expire after 24 hours) and cannot be renewed without a refreshToken. Most people also do not rely on JWTs to write important information (like password reset) because there are more secure alternatives for these specific use cases. As an aside, if someone gets script access to your SPA, you're already very far up shit creek. If your user types in any sensitive information like a password to login you've lost the war. Securing the JWT is the very least of your concerns at that point.

geofft 8y ago

There are two important attributes of a password: they're (often) human-memorable and prone to reuse / inexact reuse on other sites, and they're a long-term authentication token. JWT refresh tokens have the second attribute. But so are many other things, like regular old cookies that don't expire for weeks or months, which browsers store on a regular basis. If you're logged into HN you have one of these. While the HN cookie is HttpOnly, this isn't really putting it in more-secure storage: an XSS attack against HN can just issue whatever API requests to HN it wants, even though it can't easily walk off with a copy of the cookie.