Don't recommend JWT

[sethherr]

don't use JWT. JWT terrifies me, and it terrifies all the crypto engineers I know. As a security standard, it is a series of own-goals foreseeable even 10 years ago based on the history of crypto standard vulnerabilities. Almost every application I've seen that uses JWT would be better off with simple bearer tokens.

• tptacek on HN post

Also, link to a longer comment from him about why JWT is a bad plan.

[brunocascio]

So, what do you recommend? I've seen subjective opinions and some nonsense as well.

[sawmurai]

The only real problem I am aware off is that - if you adhere to the standard - the client can prevent/tamper with the encryption of tokens. That would indeed be a problem.

[nsteinmetz]

There are also macaroons but I don't have my own feedback yet on this

http://evancordell.com/2015/09/27/macaroons-101-contextual-confinement.html

[imerkle]

Whats the alternative of JWT ?

[tuupola]

Whats the alternative of JWT ?

Fernet is nice. Bad thing is the project seems to be pretty much dead. At least the maintainers have been in radio silence for a while.

[bf4]

JWT is just a way to make a token whose contents can be authenticated. If all you need is a token, JWT gives you nothing.

There's details around for generating a good token, in general. Assuming you've generated a token, the next question is how to use it: will you create an authorization token and refresh token like with oauth2? will you create a token and call it an 'api key' and just given it to the user? Will you require a 'client id', along with the 'client secret/api key'?

Also, if the authorization is for a web app, cookies make a good transport mechanism, especially if you set HTTP only and secure true.

Avoiding CORS is useful since it costs an OPTIONS preflight request. If we want to authenticate all requests on same domain, having an nginx proxy and avoiding CORS altogether makes the most sense (esp if we think of CORS as a way to improve upon JSONP) https://stackoverflow.com/questions/869001/how-to-serve-all-existing-static-files-directly-with-nginx-but-proxy-the-rest-t

see https://auth0.com/blog/2015/03/10/blacklist-json-web-token-api-keys/ https://stormpath.com/blog/build-secure-user-interfaces-using-jwts https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

In terms of security, all API calls should be using https and there is little difference in putting the token in headers or as part of the query string
set HTTPS only cookie

CSP, HSTS, CORS, WTF

[imerkle]

Here in what i came up with.

1. I'm creating jwt encoding users id with a short ttl of 30 mins and creating a refresh token ( random token generated not jwt stored in redis )
2. im passing the jwt token and refresh token back to client (or server requesting my api) and they save it.
3. At each request they send me the jwt token via header authorization bearer and i authenticate the jwt to get the user id.
4. if jwt is unauthenticated then i ask for refresh token and use it to verify id (stored in redis) and recreate the jwt and refresh token.
5. Since after every 30 mins , jwt will expire its a mess to ask for refresh token and do extra round trip so im doing a periodic refresh of jwt after every 29 mins(or so) using refresh token stored in client.

What are the flaws in it ?

[hjr3]

I agree that JWT should not be recommended. JWT (JSON Web Tokens) is a Bad Standard That Everyone Should Avoid does a good job of explaining the issues as well.

[Maikuolan]

@netcode Is there any final decision regarding JWT? Whether to accept/reject pull request #69 (currently open) could be influenced by any final decision regarding this issue.

Edit: Merged for now, seeing as the PR only adds links for information which already exists anyhow, and doesn't really change the context of the information already available.

[geeknik]

Stop Using JWT for Sessions
Stop Using JWT for Sessions Part 2: Why Your Solution Doesn't Work

Things to use instead of JWT

[netcode]

@Maikuolan , not yet , there is a debates all over the internet and inside our company too :D.

How about add a note regarding the issue raised here and the outside articles , what do you think guys ??

[Maikuolan]

I'd be in favour of that. With no clear consensus (and, depending whether one is in favour of JWT or against it, using it could be considered really good, or really bad advice), I think, adding a note to explain both sides of the argument, with appropriate links (pointing to some resources for how to use JWT, reasons to use it, reasons to avoid it, etc), would probably be the best solution for now.

[bf4]

@Maikuolan Following up my original comment and responding to subsequent ones, I think it would be beneficial to point out that from a security point of view, JWT can only authenticate data. It is, itself, orthogonal to authenticating a user session.

Let's consider the use case of an authentication token:

1. It identifies an authenticated user

Let's consider the use case for a JWT:

1. You want to encode information in the session
2. You want to authenticate that information
3. You DON'T need any session-specific information to respond to that request

Let's consider the number one misuse of JWT for authentication:

1. You want to identify an authenticated user
2. You encode the user_id in a JWT and return it as the session token
3. A request comes in with the session token
4. You decode the JWT session token and authenticate it
5. You look up the user from the information in the session token

You'll notice that if we omit the steps with the word 'JWT' in it, you're just describing a session id as commonly used. You're still hitting a database or datastore to look up the user, but using extra CPU cycles to encode and decode the JWT, as well as more bandwidth, since it is bigger than a simple session id. Moreover, if you're serving data via SSL, authentication is less important. Moreover, if you're storing your session in a secure cookie, it's already encrypted, so encoding it has no additional benefit.

So, unless you have services that can answer a request solely based on the contents of the JWT, you're just wasting CPU cycles and bandwidth. This is especially relevant in CPU-bound applications such as Node.js.

What's really frustrating is that there's there this 'cookie vs JWT' debate. Which makes no sense because if you're using an HTTP header for authentication, please to remember that cookies are headers and JWT is a spec for encoding authenticated data. Unless you think it's reasonable to debate whether it is better to use 'Keys vs. Values' in hash/map or parameter.

[tuupola]

While we are at it, I would appreciate feedback on the Branca token spec which I have been working on as a secure alternative to JWT. Since it defines only token format and encryption scheme you can still use same payloads as with JWT.