8 ms·

Was about to write a rant that it's still not better than cookies & sessions, something that has been standard waay longer than JWT. But this video says all I

Was about to write a rant that it's still not better than cookies & sessions, something that has been standard waay longer than JWT. But this video says all I have to say (2018): https://www.youtube.com/watch?v=JdGOb7AxUo0 https://www.youtube.com/watch?v=JdGOb7AxUo0 1 sec takeaway (More in the video): https://i.imgur.com/vUYTYfS.png https://i.imgur.com/vUYTYfS.png That said, JWT's are great for stuff like 2-Factor via email link or redirecting from one domain to another. Single use, which it was built for.

twic 7y ago
JWT is just a particular format for cookies.
zaiste 7y ago
I've written such a rant almost a year ago. [1] The article shows how to build a « RESTful » API secured with sessions implemented using regular cookies: simpler & without unnecessary complexity. [1]: https://zaiste.net/creating-secure-rest-api-nodejs-without-jwt/ https://zaiste.net/creating-secure-rest-api-nodejs-without-j...
- codezero 7y ago
  I don’t see any mention of cookies in that post except about an upcoming post. Does your framework provide the persistence on the client side for authentication, or does it rely on the client to maintain that token?
- Scarblac 7y ago
  That's nice, and how it was done for decades. But I'm looking at JWT in a context where we have an application with a REST API, third parties paying us for licenses want to write frontends running on their own domains using to that API, and authentication servers are run by end user organizations that manage their own users. Our API knows that that organization's auth server is allowed to sign tokens, the third party frontends can obtain those tokens and send them to our API, and it works (or so I hope, I'm in the reading up on all this stuff phase). Sessions using regular cookies just don't.
schnable 7y ago
JWT has many uses that have nothing to do with web browsers. The author doesn't mention anything about web browsers in the post. This line of JWT criticism needs to go away unless JWTs are being discussed specifically in a browser-based scenario.
hujjji 7y ago
I have implemented JWT with not much java code and only supporting one encryption standard. It was easily implmeneted, easy to understand, secure by design and not open to any of those security issues because there was no magic lib which would have allowed for some downgrade attack. And what did it actually solve? Session stickyness. Simple and easy.
com2kid 7y ago
JWTs are nice because the same authentication scheme can be used for applications and websites. Basically a bunch of endpoints can be put up, and if they use JWTs, it is easy to hit those endpoints from any type of app. Cookies can of course be used, but that requires pulling cookie jars into native code. Perfectly do-able, but also super awkward and potentially error prone. e.g. I remember using apps on Windows that required me to clear my Internet Explorer cookies if the native app's auth got into a broken state! (Things aren't that bad anymore) JWTs are also nice because I can easily write services that authenticate to each other. I can have a service running on my backend that authenticates its limited access service account, gets a JWT, and goes and talks to another service. Could I pass around cookies? Sure, but it'd be more work and more complicated than "attach this JSON blob". Cookies are nice if everything is browser based, but I'd argue that isn't the best way to build services. (And finally, the amount of time I've spent debugging JWT issues < the amount of time I've spent debugging cookie issues!)
- ascotan 7y ago
  There is no need to write to a cookie in server-to-server auth, just pass an auth token back in a custom header. No JWT required. Cookies are for offline users.
  - com2kid 7y ago
    > just pass an auth token back in a custom header. At that point why not just use JWT? If my auth service provider already uses JWT (which it does), and all the platforms I am writing on have a provided library that consumes JWT (which they do), then why would I go with a custom header? Also having uniformity of code patterns is nice. My web service uses the same authentication scheme as my native apps. Heck my backend DB knows how to look JWT tokens and apply permissions correctly.
snak 7y ago
Well, for a long time there was no SameSite browser support for cookies, CSRF was a vulnerability (excluding STP and other techniques to avoid it).
- tmikaeld 7y ago
  You're right, SameSite became properly supported just a year ago for the majority of browsers. Reference: https://caniuse.com/#search=SameSite https://caniuse.com/#search=SameSite
shkkmo 7y ago
We use JWT for doing time and ip address limited cross domain redirection. We also use it for partners who want to provide sso access to our site with having to implement a full oAuth. They just provide us with their public key and use any of a number of libraries for to generate a JWT with the ip address and an short expiration and an email. Once we receive a JWT key and validate it using their public key (and other associated fields) we establish a standard cookie session.
- stazz1 7y ago
  This sounds like the [only?] intelligent (and also unintendend?) use case for JWT
nijave 7y ago
That video is ridiculous. The whole time is spent talking about how cookies are superior to local storage which has little to do with JWT. You can use JWT and store it in a cookie. Session cookies are most certainly not automatically signed. Signing a session ID provides absolutely no value (signing claims, however, does). Revocation is exactly the same for both of them. JWT has a standard jti field for the session ID. I'm also not sure why you'd store all of a user's information in a JWT. You can just put in the minimal information to accomplish what you need.
- tmikaeld 7y ago
  If you cryptographically sign the session cookie, as suggested in the video, then you accomplish the exact same thing as a JWT token - so, then why use JWT at all, if you going to look up the session data from the database in any case. JWT was meant to be stateless, if it's not, then it's just a layer of unnecessary complexity with potential security and implementation flaws.
  - foray1010 7y ago
    depends on if need to call other apis like microservices, you can use the JWT on behalf of the user to request the contents from other services. JWT also introduces `scope` which determine services user consented and allowed your backend to call. These things are not supported by a simple session cookie.
    - idoubtit 7y ago
      That's precisely the use case for JWT I recently had to work with, where cookies are irrelevant. The web server gets a token from the API server, then prepares a few JSON messages that the web client will send asynchronously with JS. Since each message content is signed, the web client can't tamper with what is sent to the API. JWT was perfect for this 3-tiers messaging.
      - Spivak 7y ago
        I mean is all this complexity really worth "I can send data to an untrusted client so that it can later send it back to me?" compared to just storing that data somewhere like Redis?

twic 7y ago

JWT is just a particular format for cookies.

zaiste 7y ago

I've written such a rant almost a year ago. [1] The article shows how to build a « RESTful » API secured with sessions implemented using regular cookies: simpler & without unnecessary complexity. [1]: https://zaiste.net/creating-secure-rest-api-nodejs-without-jwt/ https://zaiste.net/creating-secure-rest-api-nodejs-without-j...

codezero 7y ago
I don’t see any mention of cookies in that post except about an upcoming post. Does your framework provide the persistence on the client side for authentication, or does it rely on the client to maintain that token?
Scarblac 7y ago
That's nice, and how it was done for decades. But I'm looking at JWT in a context where we have an application with a REST API, third parties paying us for licenses want to write frontends running on their own domains using to that API, and authentication servers are run by end user organizations that manage their own users. Our API knows that that organization's auth server is allowed to sign tokens, the third party frontends can obtain those tokens and send them to our API, and it works (or so I hope, I'm in the reading up on all this stuff phase). Sessions using regular cookies just don't.

schnable 7y ago

JWT has many uses that have nothing to do with web browsers. The author doesn't mention anything about web browsers in the post. This line of JWT criticism needs to go away unless JWTs are being discussed specifically in a browser-based scenario.

hujjji 7y ago

I have implemented JWT with not much java code and only supporting one encryption standard. It was easily implmeneted, easy to understand, secure by design and not open to any of those security issues because there was no magic lib which would have allowed for some downgrade attack. And what did it actually solve? Session stickyness. Simple and easy.

com2kid 7y ago

JWTs are nice because the same authentication scheme can be used for applications and websites. Basically a bunch of endpoints can be put up, and if they use JWTs, it is easy to hit those endpoints from any type of app. Cookies can of course be used, but that requires pulling cookie jars into native code. Perfectly do-able, but also super awkward and potentially error prone. e.g. I remember using apps on Windows that required me to clear my Internet Explorer cookies if the native app's auth got into a broken state! (Things aren't that bad anymore) JWTs are also nice because I can easily write services that authenticate to each other. I can have a service running on my backend that authenticates its limited access service account, gets a JWT, and goes and talks to another service. Could I pass around cookies? Sure, but it'd be more work and more complicated than "attach this JSON blob". Cookies are nice if everything is browser based, but I'd argue that isn't the best way to build services. (And finally, the amount of time I've spent debugging JWT issues < the amount of time I've spent debugging cookie issues!)

ascotan 7y ago
There is no need to write to a cookie in server-to-server auth, just pass an auth token back in a custom header. No JWT required. Cookies are for offline users.
- com2kid 7y ago
  > just pass an auth token back in a custom header. At that point why not just use JWT? If my auth service provider already uses JWT (which it does), and all the platforms I am writing on have a provided library that consumes JWT (which they do), then why would I go with a custom header? Also having uniformity of code patterns is nice. My web service uses the same authentication scheme as my native apps. Heck my backend DB knows how to look JWT tokens and apply permissions correctly.

snak 7y ago

Well, for a long time there was no SameSite browser support for cookies, CSRF was a vulnerability (excluding STP and other techniques to avoid it).

tmikaeld 7y ago
You're right, SameSite became properly supported just a year ago for the majority of browsers. Reference: https://caniuse.com/#search=SameSite https://caniuse.com/#search=SameSite

shkkmo 7y ago

We use JWT for doing time and ip address limited cross domain redirection. We also use it for partners who want to provide sso access to our site with having to implement a full oAuth. They just provide us with their public key and use any of a number of libraries for to generate a JWT with the ip address and an short expiration and an email. Once we receive a JWT key and validate it using their public key (and other associated fields) we establish a standard cookie session.

stazz1 7y ago
This sounds like the [only?] intelligent (and also unintendend?) use case for JWT

nijave 7y ago

That video is ridiculous. The whole time is spent talking about how cookies are superior to local storage which has little to do with JWT. You can use JWT and store it in a cookie. Session cookies are most certainly not automatically signed. Signing a session ID provides absolutely no value (signing claims, however, does). Revocation is exactly the same for both of them. JWT has a standard jti field for the session ID. I'm also not sure why you'd store all of a user's information in a JWT. You can just put in the minimal information to accomplish what you need.

tmikaeld 7y ago
If you cryptographically sign the session cookie, as suggested in the video, then you accomplish the exact same thing as a JWT token - so, then why use JWT at all, if you going to look up the session data from the database in any case. JWT was meant to be stateless, if it's not, then it's just a layer of unnecessary complexity with potential security and implementation flaws.
- foray1010 7y ago
  depends on if need to call other apis like microservices, you can use the JWT on behalf of the user to request the contents from other services. JWT also introduces `scope` which determine services user consented and allowed your backend to call. These things are not supported by a simple session cookie.
  - idoubtit 7y ago
    That's precisely the use case for JWT I recently had to work with, where cookies are irrelevant. The web server gets a token from the API server, then prepares a few JSON messages that the web client will send asynchronously with JS. Since each message content is signed, the web client can't tamper with what is sent to the API. JWT was perfect for this 3-tiers messaging.
    - Spivak 7y ago
      I mean is all this complexity really worth "I can send data to an untrusted client so that it can later send it back to me?" compared to just storing that data somewhere like Redis?