How to Use JSON Web Tokens

https://github.com/dwyl/learn-json-web-tokens/blob/master/README.md

by ristem • 8 years ago

260 128 8 years ago

github.com

Dowwie• 8 years ago

JWTs are radioactive. Proceed with caution.

fastbeef• 8 years ago

I keep hearing this. Is there a good writeup available?

tstieff• 8 years ago

The parent comment isn't very helpful, but from what I understand people dislike JWTs because it makes it hard to invalidate a session without some sort of work-around. For example, you can use 2 tokens, one short lived, and one long lived to get around the invalidation problem, but then you will need to occasionally validate that both tokens are still valid, and that state needs to be stored, and now you're storing some state, which is semi-contradictory to the purpose of a stateless-token. Here's a more detailed write-up from another poster -- https://news.ycombinator.com/item?id=12332119

lkschubert8• 8 years ago

It's a combination of the other comments response about having to still manage state for invalidation and the issue with the none algorithm. JWTs specify the algorithm their signature was encoded with in the alg field of the header. There was a decent portion of JWT libraries that by default honored the alg : none. This would allow the algorithm field to be changed to none even though the JWT had a signature and the libraries would successfully validate the JWT.

danesparza3• 8 years ago

On using JWT's for sessions (which I think most folks assume would be a primary use case) I found this:

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...

Also: it's very easy to abuse JWT tokens by storing them inappropriately... https://stackoverflow.com/a/27301616/19020

m3nu• 8 years ago

JWTs can be read by every script you add to your site, making XSS attacks easier. A cookie with the HttpOnly flag prevents this. I also found cookies easier to use, since the browser handles them and you don't need to attach headers to each request.

Any other important concerns or which way is recommended currently?

CiPHPerCoder4• 8 years ago

Blog post: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

DEFCON CPV talk: https://paragonie.com/files/talks/NoWayJoseCPV2018.pdf + https://youtu.be/RijGNytjbOI

Alternative design that isn't radioactive: https://paseto.io

Apologies if this wasn't more readily available or commonly known. I'm worse at marketing than I am at engineering.

StevePerkins2• 8 years ago

Most of the "discussion" on this topic spins out of this blog post: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba.... Which unfortunately is:

1. A bit unnecessarily abrasive and hysterical in its style, and

2. Comes from a PHP consulting firm, promoting their own alternative proposal (which hardly anyone else seems to discuss or use). So I think #1 above is really about drawing eyeballs and selling services, more so than providing clear information for a newcomer to follow.

JWT does have its issues, though. They basically break down into two points:

1. Because of its distributed nature, there's no built-in way to invalidate a JWT prior to its natural expiration. You have to roll your own approach for this, typically some sort of whitelist or blacklist mechanism (which defeats some of JWT's advantages).

2. By default, the spec and its major library implementations allow JWT's to specify a number of different signing algorithms (including "None"!). This is dangerously nonobvious for newbies. Best practice is to configure your code to only allow a limited number of algorithms (i.e. one).

netvarun• 8 years ago

tptacek posted some good commentary on this a while back - https://news.ycombinator.com/item?id=14292223

ynniv3• 8 years ago

They're a complicated solution to a problem that you almost certainly don't have. Storing session data in a private datastore using a long random session identifier as the key is simpler, more secure, and more flexible than JWT.

andybak2• 8 years ago

That's the conclusion I've come to. I wished someone would have saved me a few brain cells and told me that when I first heard about the damn things.

schnable3• 8 years ago

This meme is getting out of hand. Yes, JWTs may be inappropriate compared to putting a session id in a cookie, but there are many uses for JWTs outside of web app session handling. There are a couple serious implementation pitfalls to be aware of, but the bottom line is that JWT is a convenient and standardized way to construct a secure bearer token.

Despite the pitfalls, most folks that need a bearer token format (not just a web session) are probably better off using JWTs than rolling their owns solution.

ynniv3• 8 years ago

The number of projects that truly "need a bearer token format" is roughly the same as the number of projects that truly "need a blockchain".

danesparza3• 8 years ago

There are other ways to pass claims -- like using bearer tokens in the HTTP header, or using OAuth 2. (All with TLS, of course)

sprt• 8 years ago

Yes, JWTs don't bring anything new to the table. In fact, most articles promoting their use don't even explain why you should use them. This is cargo cult programming at its utmost.

orf• 8 years ago

There are many ways to do many things. That doesn't make it cargo cult programming.

Encoding your claims as a JWT is useful because there are many libraries that work with this, it's a known format (and one that's not tied to any particular transport), and is really good for creating stateless authentication systems using asymmetric keys.

If you're interested in the differences between JWTs and something like OAuth (which really are two different things entirely) then you can visit https://google.com and type in "JWT vs Oauth2". Answers will appear on your screen.

schnable3• 8 years ago

JWT is just a standard for bearer tokens (including those used by OAuth 2).

danesparza3• 8 years ago

I originally thought so myself. But RFC 7519 (https://tools.ietf.org/html/rfc7519) is different from RFC 6750 (https://tools.ietf.org/html/rfc6750) -- and the two don't mention each other's implementation.

endiangroup• 8 years ago

A small Go library we wrote to centrally manage distributed session tokens such as JWT inspired by CAS: https://github.com/endiangroup/compandauth. Main highlight is central revocation, locking and unlocking of distributed sessions

The core concepts can be translated into any language that supports integers, happy to reference any alternative implementations.

michelpp• 8 years ago

This is a good Javascript-centric writeup. This caught my eye thought:

Since JSON Web Tokens (JWT) are not signed using asymmetric encryption ...

You don't have to, but can of course sign your JWTs with asymmetric keys, and many libraries support this. Third party token issuers (firebase, google, auth0) require asymmetric, since they're clearly not going to share a secret with you.

Asymmetric also provides two-way token verification: The issuer signs the token with a private key, and receivers of the token can then verify that the token is legitimate using the issuers "well-known" public key.

gregmac• 8 years ago

I've dealt with and used JWTs in a few different applications, and all of them have used assymetric keys, and used as tokens passed between different systems. Keeping the private key only on the issuing system is more secure (or even essential, depending on what you're doing).

If you're authenticating on the same system, you could get away with symmetric, but then the use of JWTs may no longer make sense vs just using a random key stored persistently on the server (eg, for session cookie, "remember me" or "forgot password" token) -- I actually can't think of a case where using JWTs makes sense if you have access to persistent storage. By storing the random value you can also revoke it server side, which you can't do normally do with JWTs.

KaiserPro3• 8 years ago

JWTs are useful, but there are a few things that are not immediately obvious.

1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it

2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conform (this protects against people making their own tokens with 'None' as the signing algorithm)

I am surprised at how naive the JWT spec is. Why in this day an age is encryption a default for the _payload_? Also, why on earth is 'None' allowed as a signing algorithm? Thats just a cookie..

ForHackernews• 8 years ago

You can have unsigned, signed, or encrypted JWTs. You're correct that many JWT libraries only do signed tokens by default, but there's a whole spec devoted to encryption: https://tools.ietf.org/html/rfc7516 (whether or not your library of choice implements it is a separate question)

andrewstuart212• 8 years ago

This is one of the things I truly appreciate about JWT. They made it a) easy and b) possible to do signing, encryption, or both. If you've ever taken a shot at learning the specs behind SAML, the simplicity of JWT is hugely refreshing.

ros65536• 8 years ago

As mentioned in the article you might want the token to be read by the users. Such as issuing a token with a expiry date that you want the user to regenerate. Although If anything the JWT libraries should have encryption enabled by default.

moduspwnens14• 8 years ago

It can also be helpful if:

- your system is distributed

- you don't want to be keeping a decryption key secure and in-sync across many (and potentially less-trusted) nodes

- the JWT contains attributes useful to the system (e.g. role, user ID, etc.)

You'll probably still be keeping track of a public key of whatever's signing it (to verify authenticity), but that isn't a secret. And then you can still securely trust

manigandham• 8 years ago

To be clear, cookies are an HTTP header field that can carry any text data you want. You can pass plain text, JWTs or any other encrypted payload (which many web frameworks do automatically).

JWTs aren't comparable to cookies, they're just a standard way to sign data.

pkulak• 8 years ago

His or her point was that if you don't sign and/or encrypt, there's no benefit over a standard cookie.

mattferderer2• 8 years ago

1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it

Not a JWT expert but isn't this the point of a JWT or am I missing something. Sharing data between servers & clients while being able to make sure the data wasn't changed.

2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conform (this protects against people making their own tokens with 'None' as the signing algorithm)

People do this?? Why?

Freak_NL2• 8 years ago

Libraries did that. Most now guard against this by forcing the developer to explicitly enable the 'None' algorithm. Normally you don't need it, and certainly never in production.

But yeah, if your server accepts JWT's, reject anything that doesn't use an algorithm from your whitelist, which usually contains just one entry.

smadge• 8 years ago

Sharing data between servers & clients while being able to make sure the data wasn't changed.

I think the main use is sharing data between the server and itself. The client shouldn’t depend on the internal structure of the token. The token should just be issued by the server to the client, and the client passes it along to subsequent requests to the server.

skywhopper• 8 years ago

Re 1), yes, it is the point, but it's not necessarily clear to everyone who looks at JWT as a solution to whatever problem they have. At a glance, a JWT looks like a binary blob. And there are cryptographic algorithms involved. So it's not a surprising leap for a newbie to assume JWTs are encrypted blobs. Introductory JWT texts rarely make this clear.

Re 2), JWT libraries often make it easy to ask "is this token valid?" And I don't think it's unreasonable to think that "validity" means "signed by the shared secret I set in this library's configuration". But it usually doesn't. It usually means "this token is internally consistent". And since alg=None is a an option most people would probably assume would not exist, much less be counted as "valid", then it's not surprising that this happens.

Basically, JWT's rendered format ensures it will be misunderstood and misused, so long as the available libraries don't enforce reasonable expectations. And from what I've seen, the library situation for JWT is pretty ugly, making a confusing standard even more confusing, instead of less so.

jka• 8 years ago

There are also a number of easy-to-make mistakes or gaps which can be introduced with the use of JWTs.

https://twitter.com/ejcx_/status/1063846166029197312 provides a great list of test cases covering the commonly reoccurring flaws.

The number and seriousness of these errors and how easy it is to make them does raise questions about how sensible it is to use JWT, unless you're really sure about what you're doing.

andrewstuart212• 8 years ago

There are a number of easy-to-make mistakes with all security software. That doesn't mean it's not worth using; it just means that we should build the tooling we need in the open as shared software, so that the wisdom of crowds prevails.

Almost exactly the same set of problems exists with signed x509 certificates, but I doubt anybody would tell you not to use them. They'd just say "make sure you don't implement your own validation, unless you absolutely have to, which you don't, and even then only with lots and lots of review/audits." The wisdom with JWT should be the same, IMO.

hinkley2• 8 years ago

You aren’t required to be competent to put out a spec. Just join a committee.

Did you ever look at the XML digital signature spec? You could drive a freight train through the holes in that one. One guy did an entire conference presentation on the ones he found (took me about a year to find nearly all of the same ones and a few more).

lambdadmitry• 8 years ago

unless you encrypt your token after you generate it

Generally it's better to avoid unauthenticated encryption. That is, encrypt-than-sign, not the other way around.

paulddraper2• 8 years ago

Why in this day an age is encryption not a default for the _payload_?

Why would it be? Why not encrypt the disk and use SSL?

Doing encryption right can be enormously difficult; why not use the transport/storage technologies that are ubiquitous?

Kalium3• 8 years ago

You're right. Doing encryption correctly can be incredibly difficult and complex. Enough so that people might miss important subtleties of the technologies at hand.

For instance, you may want the encryption of data-in-transit to be removed by the application, rather than by whatever is responsible for TLS termination. You may not want your load balancer to be capable of reading the most sensitive data of your request.

sjroot2• 8 years ago

This page doesn’t have any discussion of strategies for expiring JWT, one of the biggest security issues with this auth mechanism. Even the code sample doesn’t include an expiration.

redbeard0x0a• 8 years ago

The JWT has a built-in field called exp, which is the time the token is expired. This is built in.

However if you need to 'expire' a JWT token early, there isn't a good way to do it. If your token has a JTI, then you could add a blacklist for that JTI (say in redis, with a TTL until the token's exp time). But that is left to the implementor.

sjroot2• 8 years ago

The page mentions the ‘exp’ field, but doesn’t use it in its example. I was suggesting the author point out the fact that, if someone gets a hold of a JWT without an expiration, then your system is in quite a bit of trouble.

crescentfresh• 8 years ago

So that's what JTIs are for!! I disabled [generating] them in our app, I couldn't figure out what purpose a unique-identifier-per-jwt would have, when you could just use the jwt itself to uniquely identify itself.

incadenza5• 8 years ago

My issue here is that expiring JWTs involve adding state! The whole point of JWTs is stateless authentication, so I’ve never understood the advantage over sessions unless revoking tokens is never an option.

dec0dedab0de• 8 years ago

I recently started using JWT and had the same problem, I ended up keep the expiration very low and having the client constantly refresh when they need it, and just forget it when they don't

andrewstuart212• 8 years ago

This is a very popular conclusion when considering AuthN and invalidation. Keep the state at the provider and just prevent issuance of new tokens (whether signed certs, JWTs, etc) if/when the user requests access be revoked.

What you're really doing is externalizing your state to one already universally shared, and which we already have a lot of tools to manage: the current time.

jillesvangurp• 8 years ago

You can set a ttl in the JWT and you should. But I think you are talking about using jwts as session cookies, which is indeed not something you should be doing without having a reliable way to invalidate them if you care about reliable signout and token invalidation. For that ttls are not a great solution.

We don't currently use them for sessions, but I've been planning to. When we do, we'll have a mechanism for invalidating tokens, just like we currently do for our oauth tokens. One way would be to simply embed that in the jwt as a field and check that on each request, just like we do already with oauth. The biggest risk with either oauth or jwt tokens is somebody intercepting them and using them. This risk is about the same for both but it does need consideration.

We are using jwts internally for authorizing messages on our queues and internal API calls. Those jwts have very short ttls and don't leave our infrastructure. They typically include assertions on scope, userids, etc. I've been considering to make JWTs the native format on our queues; i.e. embed the message in the JWT rather than a jwt in the message. This would make message tampering harder for any man in the middle attacks. We already uses nonces in some of our messages so we'd be able to prevent replay attacks this way as well.

The main benefit of using jwts is that verifying them is trivial and can be done without network interaction. Very nice in a microservice type architecture. Jwts are issued on our API server are after verifying the oauth token (not jwt currently). We don't leak these tokens outside our infrastructure currently and we don't have public endpoints that would accept them in any case. None of this is new but not that common in modern REST/graphql type setups nevertheless. JWTs are probably easy enough to retrofit in most APIs that it might be worthwhile exploring this for many.

If you are interested, we open sourced our Java code for creating/verifying JWTs. Check here for an example and more code: https://github.com/Inbot/inbot-utils/blob/master/src/test/ja...

ape4• 8 years ago

Maybe in 2019 we'll stop using JSON/JS for everything

java_script• 8 years ago

Your wish has been granted. 2019 is the year of YAML as a serialization format and the return of CoffeeScript.

Disclaimer: I am a genie.

andybak2• 8 years ago

Can we go back further and have Django/Rails as the new hotness with Pjax/Turbolinks for the extra cool kids?

jondubois2• 8 years ago

I think storing JWTs might make sense for some advanced scenarios where you have multiple services with varying security requirements but when you store JWTs, you lose a lot of the benefits of having a stateless token which doesn't require a database lookup.

A possible alternative is to just make the JWT expiry very short; like one hour; then you don't really need to explicitly invalidate the token.

With a real time bidirectional transport like WebSockets, you can make the JWT expiry even shorter; like 10 minutes and you can auto refresh it by pushing a replacement token to clients every 8 minutes or so. If the expiry is so short, you don't need the ability to invalidate tokens.

Getting your laptop stolen while you are logged into a service which relies on JWT is like getting your credit card stolen; it will probably take at least 10 minutes for you call your bank to disable it.

groestl• 8 years ago

An hour could be much much too long, depending on what service you are protecting. It's long enough that even assuming that token theft is a non-stealthy operation, and the user reacts immediately, the attacker has a lot of time to execute his attack. For things like Facebook, this could include slowly scaping all user data and spreading the infection vector to other users.

As for websockets: session integrity is handled by TLS, and invalidation can be handled by closing the TCP connection. Authentication needs to happen only once, on connect.

jondubois2• 8 years ago

Storing JWTs in a store or DB is difficult because you need to manage them and that means accounting for all possible edge cases. You can't always detect when a WebSocket/TCP connection has closed from the back end. For example, if your WebSocket server crashes suddenly, all active JWTs that you keep in your external data store will be orphaned and they won't get cleaned up until you run a separate cron job (which adds a lot of complexity).

Storing JWTs in a hashmap in memory is also not ideal if you have multiple processes/servers because it doesn't account for WebSocket lost connection and reconnection edge cases; the client could reconnect to a different server/process than before.

EGreg• 8 years ago

I used to just follow whatever people said in oAuth and oAuth 2. No longer. Once I started questioning why we need all these tokens, when we will anyway have to look up access information in some database, I got pretty much no satisfying answers:

https://security.stackexchange.com/questions/161734/why-does...

The token may as well just be an AUTENTICATION token, such as the app’s id with timestamp signed with the shared secret. (Or even better, an asymmetric private key, where the shared secret is replaced by TWO keypairs, one from app-to-platform and one from platform-to-app.)

Then you use this app id to look things up in an Access Control List (ACL).

Then stuff becomes easy. Forget all the oAuth crap. The app is just another user with an ID in your system. Users may grant access to other users, for different streams of data. The access can have various read/write/admin levels etc. It can be changed anytime. Finally, users can have LABELS (or Roles) which determine in one fell swoop what an app can do. That is similar to “scopes” in oAuth.

I don’t just talk about it — this is how we handle it in our platform:

https://qbix.com/platform/guide/access

superasn2• 8 years ago

One of the biggest advantages of JWT is that is saves up on database reads which can be significant when you have million+ logged in users.

I think that is probably thinking of time when you had to do everything yourself (host your own mysql server, create indexes, cache, etc). Now you can easily save your sessions using stuff like DynamoDb.. it costs almost nothing and read times are blazing fast even when there are millions of rows. Doesn't make a lot of sense to use JWT after this.

amenod2• 8 years ago

Now you can easily save your sessions...

True.

...using stuff like DynamoDb..

Well, yeah, if you want to be tied to AWS and use a difficult to manage technology which is only useful in a few niche cases, DynamoDB is absolutely the right choice </sarcasm>. Otherwise Redis, Memcache or even Postgres would be a better choice. After all, session management is only a (small) part of data persistence problem.

superasn2• 8 years ago

Yes of course. That was not my point DynamoDb was just something off the top of my head. You can easily use redis or even any nosql db for that. My point was about the main advantages of JWT being fast with millions of users isn't really that big deal anymore.

TekMol• 8 years ago

At first JWTs look cool because you can log in users without managing session data on the server.

Then you think about how a user can actively log out.

Then you add session management to your server but call it 'token invalidation'.

andrewstuart212• 8 years ago

This is a problem you have with any federated token-based identity solution. Distributed logout is a hard problem which can basically be reduced to cache invalidation (insert N/N-1 hard things in CS joke here).

tptacek9• 8 years ago

This is a little like saying "this is a problem you have with ANY identity solution that looks like JWT". Yes, that's true. The reason people complain about JWT is that (a) it's the most popular solution of this shape, and (b) people use it without understanding why they're using it or whether the tradeoffs work for their application. They usually do not.

Witness everyone saying that the important feature of JWT is that it's standard and interoperable, as if that was a mandatory feature of most token-based authentication schemes; in fact, the "portability" of JWT is a security liability for --- I'll hazard --- the overwhelming majority of applications.

kevinburke4• 8 years ago

Last year I helped several different companies switch off of JWT onto JSON encrypted with secretbox, which was much more appropriate for their use case(s). No risk of accidentally using an insecure algorithm or sending secure data unencrypted to the client.

Local storage is not secure.

B-Con• 8 years ago

Note: Yes, both these methods are synchronous. But, given that neither of these methods require any I/O orNetwork requests, its pretty safe to compute them synchronously.

Found this amusing. Are node devs so used to async that disclaimers like this are necessary?

kevinburke4• 8 years ago

yes, Node is single threaded so any one thread that blocks the event loop for a significant amount of time becomes a significant performance bottleneck. Generally functions like bcrypt require an asynchronous API.

firemelt• 8 years ago

Is it safe to put jwt in local storage?

How to Use JSON Web Tokens

Related Stories