What is a JWT?
JWT, short for JSON Web Tokens, is a compact, URL-safe way of representing claims (information) to be transferred between two parties, the client and server. Think of it like a secret message in the form of a cryptographically signed note, which can only be understood by the intended recipient.
Structure of a JWT
A JWT has three distinct parts, each separated by a dot (.):
Header: It contains metadata about the token and the cryptographic algorithm used, usually HMAC SHA256 or RSA.
Payload: The actual data that the token carries is stored here. It's also known as the 'claims' and can include data like user details and additional metadata.
Signature: The signature is a cryptographically secured proof that verifies the sender and ensures the message wasn't altered during transit.
How Does a JWT Work?
Here's the play-by-play of JWT in action:
- A client logs in using their credentials, sending a request to the server.
- The server verifies these credentials. If they're valid, the server generates a JWT and sends it back to the client.
- The client stores the JWT, usually in local storage, and includes it in every subsequent HTTP request's header.
- The server, upon receiving these requests, verifies the JWT. If it's valid, the client is authenticated and authorized.
Why Use JWT?
JWTs are universal - any programming language can generate a JWT because they're essentially JSON. Also, they facilitate maintaining session state on the client, reducing server load, which is more scalable.
Security Considerations
While JWTs are handy, they do come with some vulnerabilities:
Token Theft: JWTs are stored on the client-side, and hence can be stolen. Always ensure your transmission is secure, preferably via HTTPS.
No In-built Invalidity Mechanism: JWTs can't be invalidated individually or in a group from a user, due to their stateless nature.
Token Size: Storing too much data in a JWT can make it heavy, affecting network performance.
Algorithm Vulnerabilities: Some algorithms in the JWT header are vulnerable to attacks. Always use secure and updated algorithms, and treat your signing keys like secrets.
In conclusion, JWTs are a potent tool in web development, providing stateless, secure, and scalable communication. Remember, how effectively you wield JWTs in your application depends on your specific needs and the level of security you require.
I hope this gives you a better understanding of JWTs! Feel free to share your thoughts 😄
Top comments (9)
"Think of it like a secret message in the form of a cryptographically signed note, which can only be understood by the intended recipient."
Well, not exactly. Anybody can reverse the content of the JWT. You just can't modify them or create your own if the server is using a private/public key signature to verify the JWTs. But if you steal a JWT, you can certainly read its content.
Not always ... The problem here is : "jwt is an abstract" . You will never create a jwt .
You will create a jws or a jwe .
Jws is a signed jwt, the one presented here, no security about reading the body .
Jwe is an encrypted jwt, you can't read it without the private key .
Jws can be useful because you can read the expiration, or validate the signature with a jwks .. but the content is readable
Oh cool, I was just using jwt.io as my source so I guess that's a jws implementation.
I'm quite curious on the server-token validation process.
The JWT doesn't store username and password information (encrypted) and reauthenticates right?
Does the server contain a database that holds valid token signatures or is there a database-stored token field within the payload that the server uses to verify with?
The power of JWTs is that you can forego the use of any type of key store. Typically you'd store things like the username, user email, user phone number, etc in your JWTs payload. Or as they mentioned in the article, you can also store more metadata like the expiration time of the token, issuer of the token, subject of the token, and a bunch more.
You should have a special private token on your server which will be used to sign a JWT (and send it to the user) on events like a user log in. That same key would be used on subsequent requests from the user, where the JWT would be sent alongside the users request to the server. The server will now verify the JWT using the same special private token. If the token is valid, they can be authorized to access certain resources. bingo.
Thank you for writing this article. I am beginner in backend. It helps me a lot to understand about JWT.
Great article thank you for sharing
Well written
Thank you this was a great article