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.

[Maikuolan]

Thanks @bf4 for the detailed reply and additional information, and thanks @tuupola for providing a possible alternative for us to look at. :-)

I think, one thing that could probably be safely agreed upon, regardless of which side of the fence people sit on in regards to JWT, is that thus far, there isn't a huge amount of context provided by the checklist at this point in terms of what we mean by "authentication". Maybe that would be a good starting point (e.g., providing some more context in the checklist for the types of authentication we're talking about, the context where such authentication should be used, what for, etc)?

[c4milo]

I don't see everything being wrong with JWT, there are some non recommended ways of using it. Recommend the safe ways of using it and stop spreading FUD.

[itsMattShull]

So here are my questions/scenarios if someone could clearly explain why JWT aren’t the right way and what is the right way:

• how to do authentication for users of a website
• how to do authorization for users of a website
• how to do auth for a public API that developers can use to hit endpoints
• how to do an internal API only used for the website

[bf4]

Matt- mind helping us help you by sharing what was unclear from the above? Also, any programmer that gives you 'the right way' should be ignored. Cryptographers and devs make some good arguments why JWT are often a poor data format, see above, yet it remains popular. Who is right?

B mobile phone

On Nov 18, 2017, at 2:42 PM, Matt Shull [email protected] wrote:

So here are my questions/scenarios if someone could clearly explain why JWT aren’t the right way and what is the right way:

how to do authentication for users of a website how to do authorization for users of a website how to do auth for a public API that developers can use to hit endpoints how to do an internal API only used for the website — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[itsMattShull]

I don’t know that there is clarity above. I see a lot of disagreement so I wanted to know from the side of the “JWT is a bad pattern”, what’s the best way to do what i mentioned above.

If the answers are clearly laid out and I’m just missing it, could you help point me in the right direction?

[bf4]

Matt-

Sounds like that's a separate issue you should open.

I misunderstood your question. My answers:

• How to authenticate users is a pretty big topic. If you mean how to persist user session, then the answer is usually a cookie or a token.
• How to authorize users is a pretty big topic. If you mean, how can I know what privileges a user has if I can't encode them in the session.. then your site will probably be hacked pretty quickly, since business rules of that sort need to live on the server.
• How to authenticate a public API. Is the same question and answer as the first.
• How to do an internal API: The reductive answer is 'don't expose it to the public'.

Generally, using TLS/SSL helps.

If you're wondering why my answers don't mention JWT, that's why I suggested opening a new issue. You might also want to look at the OWASP top ten. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

You wrote:

So here are my questions/scenarios if someone could clearly explain why JWT aren’t the right way and what is the right way:

• how to do authentication for users of a website
• how to do authorization for users of a website
• how to do auth for a public API that developers can use to hit endpoints
• how to do an internal API only used for the website

On Tue, Nov 21, 2017 at 11:34 AM, Matt Shull [email protected] wrote:

I don’t know that there is clarity above. I see a lot of disagreement so I wanted to know from the side of the “JWT is a bad pattern”, what’s the best way to do what i mentioned above.

If the answers are clearly laid out and I’m just missing it, could you help point me in the right direction?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/shieldfy/API-Security-Checklist/issues/6#issuecomment-346102490, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIuQvVx71c3WOcLUppBHF-lNyoyF4Muks5s4wmggaJpZM4OR6se .

[warlockdn]

Its like everyone is saying don't use JWT but I can't see anyone explaining what else to use. Too much discussions on why it sucks but no one actually says what should be done. Tired of searching the whole web for answers now.

[bf4]

Its like everyone is saying don't use JWT but I can't see anyone explaining what else to use. @warlockdn use for what? it's just a token.

no one actually says what should be done.

https://github.com/shieldfy/API-Security-Checklist/issues/6#issuecomment-314627569

https://github.com/shieldfy/API-Security-Checklist/issues/6#issuecomment-316332544

etc

Agree that this issue should have some output

[warlockdn]

@bf4 I hope you understand my frustration. I saw the comments you mentioned and I have looked at it still its the same there are tonnes of stuff like tonnes of No's but only thing that I saw was use TLS yea well that works too. In web its still ok we can use csrf and session and use it. but how will someone implement it for a mobile app which only talks through api.

Any suggestions ?

[paragonie-scott]

Its like everyone is saying don't use JWT but I can't see anyone explaining what else to use

https://paragonie.com/blog/2018/03/paseto-platform-agnostic-security-tokens-is-secure-alternative-jose-standards-jwt-etc

[brunocascio]

Finally.. if you use jwt properly, does not matter. If someone brokes your autentication even using the most secure standard, you and a lot of people will have troubles. Keep out paranoia from here..

[bf4]

if you use jwt properly, does not matter.

@brunocascio

some would say that even when it has a good use case, of which there are not many, there are better specs to use.

https://speakerdeck.com/rdegges/jwts-suck-and-are-stupid https://www.youtube.com/watch?v=GdJ0wFi1Jyo cc @rdegges

[brunocascio]

https://speakerdeck.com/rdegges/jwts-suck-and-are-stupid

Is about cookies vs JWTS. In APIs is not a valid scenario...

[bf4]

Disagree. He is an API builder. I build APIs. Cookies don’t work in certain situations, but that’s orthogonal to JWT. A cookie is a token in an http header. The point of the issue is, when you make a token, you almost certainly should not use the JWT spec to generate it.

Again, if you want to make a token, there’s a number of ways to make it. If you want to preserve state across requests, a cookie one place in the request/ response to put a session token. Someday I’ll write up my own research and experience. I point to Randall because I think he explains from a practical point of view, crypto aside, why JWT is a poor choice for authentication.

Did you know you can use secure http-only cookies over CORS from a static React site? Sounds like an API to me :) (though it’s better to avoid CORS if you can)

[brunocascio]

Did you know you can use secure http-only cookies over CORS from a static React site? Sounds like an API to me :) (though it’s better to avoid CORS if you can)

Yes, http-only flag should be used along with secure flag in order to prevent some known vulnerabilities like XSS or MiTM (at least), independent of the technology used in the frontend. Cookies mean that the server persists sessions. Standard Rest APIS are stateless :)

The problem is finding a way to make an API stateless without cookies. JWT take place here...

Anyway, I like to debate it :) So, how to implement authentication if you can't use cookies?

[warlockdn]

I guess we can just encrypt the sensitive data object too and add it to jwt token ? and whenever a request comes decrypt and use it. But would it be time consuming ?

Looked at Paseto but couldn't see a NodeJS library built on it i guess it was written in PHP

let's keep the conversation running its time we come to a solution.

Someday I’ll write up my own research and experience. @bf4 do it soon if you could