3 ms·

And yet he didn't explain how JWT differs from session cookies. I suppose I'll never learn. (looks hopefully at the HN crowd)

pat2man 7y ago
From my perspective, it is a session cookie + some other verifiable attributes. For instance if you are using OAuth you can include the OAuth client ID in the JWT. Now you don't need to look it up each time.
vinceguidry 7y ago
Cookies have a special storage place in the browser and limited storage space. This limitation makes it so that usual practice for cookies is to store only a UUID-style identifier client-side and the rest of the data for the session server-side, necessitating a database round-trip before you can even know who's hitting your server. JWT allows you to use the browser as the fatter client that it has been slowly growing into. Because JWT is JSON, it can store anything, and you're only limited by how large you want to make your web requests. (they're sent with each request) At the end of the day, they're both ways to build state into a stateless protocol.
shantly 7y ago
JWT is just some arbitrary JSON data, with a few customary fields, cryptographically signed by whichever system issued it. You send it to the client, which may be a browser or mobile app or whatever, and they send it with each request to any related systems. A system receiving a JWT can verify that the stuff in it was certified as true or accurate by the issuing system, given only the correct keys to check the signature and no further info about the user. One might, for example, put user identity info & user roles (for permissions) in a JWT. This can be useful for e.g. checking login status at proxy or cache servers without having them connect to a database or ask other systems (so, works very fast), for microservice bullshit, or for systems with lots of access points and unified login (think Google, with Youtube, Gmail, Docs, and so on—I don't think they use them, but that's the sort of situation in which one might) The main downside is that you can do stupid crap with them like not set an expiration, and you can't really expire tokens prematurely (say, on user role changes or on user deletion) without re-introducing some centralization. Neither are crippling but they do make it less the magic bullet than one might hope.

pat2man 7y ago

From my perspective, it is a session cookie + some other verifiable attributes. For instance if you are using OAuth you can include the OAuth client ID in the JWT. Now you don't need to look it up each time.

vinceguidry 7y ago

Cookies have a special storage place in the browser and limited storage space. This limitation makes it so that usual practice for cookies is to store only a UUID-style identifier client-side and the rest of the data for the session server-side, necessitating a database round-trip before you can even know who's hitting your server. JWT allows you to use the browser as the fatter client that it has been slowly growing into. Because JWT is JSON, it can store anything, and you're only limited by how large you want to make your web requests. (they're sent with each request) At the end of the day, they're both ways to build state into a stateless protocol.

shantly 7y ago

JWT is just some arbitrary JSON data, with a few customary fields, cryptographically signed by whichever system issued it. You send it to the client, which may be a browser or mobile app or whatever, and they send it with each request to any related systems. A system receiving a JWT can verify that the stuff in it was certified as true or accurate by the issuing system, given only the correct keys to check the signature and no further info about the user. One might, for example, put user identity info & user roles (for permissions) in a JWT. This can be useful for e.g. checking login status at proxy or cache servers without having them connect to a database or ask other systems (so, works very fast), for microservice bullshit, or for systems with lots of access points and unified login (think Google, with Youtube, Gmail, Docs, and so on—I don't think they use them, but that's the sort of situation in which one might) The main downside is that you can do stupid crap with them like not set an expiration, and you can't really expire tokens prematurely (say, on user role changes or on user deletion) without re-introducing some centralization. Neither are crippling but they do make it less the magic bullet than one might hope.