How to Use JSON Web Tokens
github.com
How to Use JSON Web Tokens
1–10 of 135 posts
Re: How to Use JSON Web Tokens
#2JWTs are radioactive. Proceed with caution.
Re: How to Use JSON Web Tokens
#3JWTs are radioactive. Proceed with caution.
I keep hearing this. Is there a good writeup available?
Re: How to Use JSON Web Tokens
#4JWTs are radioactive. Proceed with caution.
I keep hearing this. Is there a good writeup available?
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
Re: How to Use JSON Web Tokens
#5JWTs are radioactive. Proceed with caution.
I keep hearing this. Is there a good writeup available?
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.
Re: How to Use JSON Web Tokens
#6There are other ways to pass claims -- like using bearer tokens in the HTTP header, or using OAuth 2. (All with TLS, of course)
Re: How to Use JSON Web Tokens
#7Earlier quoted context omitted.
I keep hearing this. Is there a good writeup available?
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…
At work we use JWT strictly within our own infrastructure, and opaque tokens for requests coming into our API gateway. This gives us a single point to check tokens are still valid, after which a JWT gets passed back to the backing service. The actual service internally can trust that the token it received is still good to use, in many cases not needing to do any further queries to get user details as their encoded in the token.
Re: How to Use JSON Web Tokens
#8JWTs are radioactive. Proceed with caution.
I keep hearing this. Is there a good writeup available?
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
Re: How to Use JSON Web Tokens
#9JWTs are radioactive. Proceed with caution.
I keep hearing this. Is there a good writeup available?
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?
Re: How to Use JSON Web Tokens
#10A 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.