If you are going to use JWT besides its failings, you should use it safely. But not all advice in this piece is equally strong.
1. RS256 vs ES256 - you shouldn't use either. RS256 not just an old standard on the way out. With safe keys sizes tokens are often going to be too large and signing too slow for you. ES256 on the other hand, suffers from many theoretical flaws and at least one practical flaw that (complete breakdown if nonce is reused) that helped jailbreak the PS3.
The only reasonable asymmetric signature algorithms implemented for JWT are Ed25519 and Ed448, but they are still not supported by most libraries.
2. Key IDs - always include them, even if you're just using 1 key for now. Otherwise you cannot rotate keys securely without having to reject all existing tokens.
3. Have relatively short lifetimes for JWTs if you're not using a blacklist. A token that lasts for 180 days with no possible way to revoke it is a dangerous little thing.
4. Always verify that you only accept JWTs signed by the algorithm you're expecting. Otherwise you might be fooled by a JWT signed with HMAC-SHA256 by your RSA public key (which is known to the attacker:
https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
5. Under no circumstances accept tokens signed with "none". The standard is just bonkers.
6. Rotate keys every month if you can, not every 2 years. This is keeping your joints well-oiled.
7. Damage control is still possible when using JSON Web Signature (JWS). JSON Web Encryption (JWE), on the other hand, is just a train wreck that is very hard t ouse properly. Avoid it all costs. PASETO provides a viable alternative for most cases it makes sense to use an encrypted token.
8. If you can avoid JWT, just avoid it. It's just too hard to implement securely. In the past there weren't any widespread alternatives, but PASETO is supported in most common platforms now and is clearly a better option.
There usually is a "don't use JWTs" alternative, but it's almost always shared secrets. Passwords, cookies, or some variation on that concept.
In that light, even poor jwt hygiene is better than none as long as you avoid a few key mistakes.
But on the other hand, security is, at it's core, the assessment of what guarantees a given technology can actually provide versus what you _depend_ on it to provide. So better tech can be worse security if you overestimate its capabilities.
I haven't implemented PASETO but I was thinking about adding support for another language. If I were to implement it, I would just use libsodium for most of the cryptographic primitives whenever possible since the reference PASETO implementation uses it as well as most of the other language implementations too (Except for the Go version).
PASETO does seem like a cryptographic secure alternative that addresses the pitfalls of the JOSE standard and has most of the mitigations mentioned in this blog-post (No cryptographic-algorithm agility) and it supports the same functionalities of JWT/JWE and JWS. So I am convinced on getting that standardized, but it also needs XChaCha20-Poly1305 AEAD to be standardized too [0].
Fernet was also around as being a secure alternative, but it has been mostly replaced by Branca [1] and PASETO.v2.
I haven't implemented but like what it's going for. Modern crypto is all about making it easy to do the right thing without thinking about it and PASETO does that well with its versioning scheme and relying on established crypto from libsodium.
As long as all supposed consumers of JWT are on my infrastructure I prefer to make all tokens revokable. Tokens TTL is smaller than 1 hour so I keep 1 hour worth of revocations on all servers (pushed via queue). If key is on list it is refused (without database hits)
Now, what is the (currently accepted) best way to store that refresh token in a ReactJS frontend? I send the JWT via Cookies as “httpOnly; Secure”, would the refresh token go the same route? If so, wouldn’t compromising of the JWT also mean the same for the refresh token? And therefore give the person unlimited access until key-rotation?
Or, like with Oauth2, is the idea that JWT gets transmitted back to the server with every request, and the refresh token only when needed and therefore having a slightly smaller risk of intercepting both keys (assuming the refresh token is not stored in cookies)?
I use Auth0 for my React frontend. The Auth0 folks themselves say you shouldn't use refresh tokens for single page apps, you can't trust the client-side.
Instead of using refresh tokens, they have a "silent authentication" mechanism[1]. The idea is: sometime before the user's initial token expires, your app goes through the silent-auth process in an invisible iframe. Assuming the user's authentication credentials are still valid, the invisible iframe will eventually use the browsers postMessage() functionality to deliver a new token to the main app's frame, your app then quietly starts using this new token that has a new cryptoperiod.
The silent-auth mechanism doesn't use any different inputs than a normal Auth0 SSO login. Your app is constantly re-authenticating until the user is not allowed to login any more. This allows you to set short expiration times with no interruption of the user at all.
JWT and Refresh tokens dont address session issues; so the answer to your question is to introduce strong session management tools.
(Id argue that JWT is the wrong tool to use in a react front end - store that in the orchestration and implement some strong session management betweem FE and orch through an access gateway)
You should not store any token in the frontend. Instead, have a server doing that and use a classic secure cookie session. The session is bound to the token / refresh token and can then do the token management.
Alternatively, don't use access token / refresh token but an ID token. The refresh of the token will be done via the ID token and the user's session (cookie) to the OAuth provider.
In the article, they mention the refresh token needs to be revokable which I assume means that it is stored in a table in a database or other data store. When the user logs out, the refresh token is removed from the table (i.e. it is revoked).
The JWT server would check to see that the refresh token probably stored in the browser with a cookie or localStorage is valid before sending the new JWT.
From the article, refresh tokens are revokable. The whole point of JWT + refresh token is that for normal operation, you don't need to hit the database but still able to revoke a token.
unscaled|6 years ago
1. RS256 vs ES256 - you shouldn't use either. RS256 not just an old standard on the way out. With safe keys sizes tokens are often going to be too large and signing too slow for you. ES256 on the other hand, suffers from many theoretical flaws and at least one practical flaw that (complete breakdown if nonce is reused) that helped jailbreak the PS3.
The only reasonable asymmetric signature algorithms implemented for JWT are Ed25519 and Ed448, but they are still not supported by most libraries.
2. Key IDs - always include them, even if you're just using 1 key for now. Otherwise you cannot rotate keys securely without having to reject all existing tokens.
3. Have relatively short lifetimes for JWTs if you're not using a blacklist. A token that lasts for 180 days with no possible way to revoke it is a dangerous little thing.
4. Always verify that you only accept JWTs signed by the algorithm you're expecting. Otherwise you might be fooled by a JWT signed with HMAC-SHA256 by your RSA public key (which is known to the attacker: https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
5. Under no circumstances accept tokens signed with "none". The standard is just bonkers.
6. Rotate keys every month if you can, not every 2 years. This is keeping your joints well-oiled.
7. Damage control is still possible when using JSON Web Signature (JWS). JSON Web Encryption (JWE), on the other hand, is just a train wreck that is very hard t ouse properly. Avoid it all costs. PASETO provides a viable alternative for most cases it makes sense to use an encrypted token.
8. If you can avoid JWT, just avoid it. It's just too hard to implement securely. In the past there weren't any widespread alternatives, but PASETO is supported in most common platforms now and is clearly a better option.
https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
jakecraige|6 years ago
I agree that JWT has all sorts of flexibility that make it hard to use well but NIST curves work just fine.
If you think they are backdoored then sure, Ed25519 is a better option but real world constraints may require you to use a NIST curve for now.
tylerl|6 years ago
There usually is a "don't use JWTs" alternative, but it's almost always shared secrets. Passwords, cookies, or some variation on that concept.
In that light, even poor jwt hygiene is better than none as long as you avoid a few key mistakes.
But on the other hand, security is, at it's core, the assessment of what guarantees a given technology can actually provide versus what you _depend_ on it to provide. So better tech can be worse security if you overestimate its capabilities.
merlincorey|6 years ago
I have read the papers and seen the talks -- it seems fairly compelling.
[0] https://paseto.io/
return_0e|6 years ago
PASETO does seem like a cryptographic secure alternative that addresses the pitfalls of the JOSE standard and has most of the mitigations mentioned in this blog-post (No cryptographic-algorithm agility) and it supports the same functionalities of JWT/JWE and JWS. So I am convinced on getting that standardized, but it also needs XChaCha20-Poly1305 AEAD to be standardized too [0].
Fernet was also around as being a secure alternative, but it has been mostly replaced by Branca [1] and PASETO.v2.
[0] - https://github.com/bikeshedders/xchacha-rfc
[1] - https://branca.io
jakecraige|6 years ago
indeyets|6 years ago
mittermayr|6 years ago
Or, like with Oauth2, is the idea that JWT gets transmitted back to the server with every request, and the refresh token only when needed and therefore having a slightly smaller risk of intercepting both keys (assuming the refresh token is not stored in cookies)?
thecopy|6 years ago
You never store refresh tokens in a frontend. You can store access tokens (short-lived) in the frontend but you should never store refresh-tokens.
Shorn|6 years ago
Instead of using refresh tokens, they have a "silent authentication" mechanism[1]. The idea is: sometime before the user's initial token expires, your app goes through the silent-auth process in an invisible iframe. Assuming the user's authentication credentials are still valid, the invisible iframe will eventually use the browsers postMessage() functionality to deliver a new token to the main app's frame, your app then quietly starts using this new token that has a new cryptoperiod.
The silent-auth mechanism doesn't use any different inputs than a normal Auth0 SSO login. Your app is constantly re-authenticating until the user is not allowed to login any more. This allows you to set short expiration times with no interruption of the user at all.
[1] - https://auth0.com/docs/api-auth/tutorials/silent-authenticat...
ErrantX|6 years ago
(Id argue that JWT is the wrong tool to use in a react front end - store that in the orchestration and implement some strong session management betweem FE and orch through an access gateway)
FlorianRappl|6 years ago
Alternatively, don't use access token / refresh token but an ID token. The refresh of the token will be done via the ID token and the user's session (cookie) to the OAuth provider.
thesunny|6 years ago
The JWT server would check to see that the refresh token probably stored in the browser with a cookie or localStorage is valid before sending the new JWT.
kyriakos|6 years ago
thangngoc89|6 years ago