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)