What it is
A JSON Web Token, or JWT, is a compact string that carries a set of claims, such as who the user is and when the token expires. It has three parts: a header, a payload and a signature, each encoded and joined with dots. It is defined in RFC 7519. Tokens usually travel in an HTTP Authorization header as a Bearer token.
The signature lets the receiver check that the token was issued by someone holding the key and has not been changed. HS256 uses a shared secret; RS256 and similar algorithms use a public and private key pair. A JWT is signed, not encrypted, so it should not hold secrets. Libraries for creating and checking them exist for almost every language.
How I use it
- Rental Pilot's React web app signs in with Bearer tokens issued by the API.
- Chat connections are authenticated with HS256 tokens signed by the PHP API and verified by the Node chat server, with the secret shared between the two.
- Listed on my CV as part of the server work: REST and JSON APIs, JWT auth and row-level multi-tenancy.
- Permissions are still checked by the API on every request, not trusted from the screen.
JWTs are the right tool when more than one service needs to trust the same sign-in without each one calling back to a central session store. I reach for them because Rental Pilot's PHP API and its Node chat server are separate programs, and a signed token lets the chat server check a user on its own.
Questions
Are JSON Web Tokens secure?
They are safe when used with care: a strong key, short expiry, and no secrets in the payload, since it is signed but not encrypted. The server should still check permissions on every request, as Rental Pilot's API does.
Why use JWTs instead of a session cookie?
They let separate services trust the same sign-in. Rental Pilot's chat server verifies the API's tokens itself, without a round trip to the API on every connection.