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

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.