A Developer's Essential Guide What is JWT?
JSON Web Token (JWT) is a compact, URL-safe token format used for securely transmitting information between parties.
Think of it as a digital passport that carries user credentials and claims in a standardised, verifiable format.
š JWT Workflow:
1ļøā£ Login Request ā User provides credentials
2ļøā£ JWT Issued ā Server validates and responds with a token
3ļøā£ Client Stores JWT ā Usually in localStorage or sessionStorage
4ļøā£ Authenticated Requests ā JWT is sent in Authorisation: Bearer
5ļøā£ Server Verifies & Responds
How is JWT Created?
A JWT consists of three parts separated by dots (.):
š¹ Header: Contains token type (JWT) and signing algorithm (e.g., HS256, RS256)
š¹ Payload: Contains claims (user data, permissions, expiration)
š¹ Signature: Ensures token integrity using a secret key or certificate
Structure: header.payload.signature
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFua2l0IiwiaWF0IjoxNjg4MDA2NDc1fQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
š JWT Payload Breakdown (Middle Part):
This is a Base64-encoded JSON and may look like this:
{
"sub": "1234567890", // Subject (user ID)
"name": "Ankit", // User name
"iat": 1688006475, // Issued At (timestamp)
"exp": 1688010075, // Expiration time (optional)
"role": "admin" // Custom claim
}
Payload Information:
The payload contains "claims" - statements about the user and
additional data:
⢠Registered Claims: Standard fields like iss (issuer), exp (expiration), sub (subject)
⢠Public Claims: Custom fields defined in JWT registry
⢠Private Claims: Application-specific data like user roles, permissions
Key Benefits:
ā Stateless: No server-side session storage needed
ā Scalable: Perfect for micro services and distributed systems
ā Secure: Cryptographically signed and optionally encrypted
ā Cross-platform: Works across different domains and applications
Important Considerations:
ā ļø Size: JWTs can become large with extensive payload data
ā ļø Security: Never store sensitive data in payload (it's Base64 encoded, not encrypted)
ā ļø Expiration: Always set appropriate expiration times
ā ļø Storage: Store securely (httpOnly cookies preferred over localStorage)
Common Use Cases:
šÆ Authentication and authorization
šÆ Single Sign-On (SSO)
šÆ API security
šÆ Information exchange between services
Pro Tips: š” Use short expiration times with refresh tokens š” Implement proper token revocation strategies š” Always validate tokens on the server side applications?
Share your experiences below! š
Top comments (0)