JWT - JSON Web Tokens for Authentication
About 2 min read
A JWT (JSON Web Token) is a token that encodes JSON-formatted data into a compact string with an attached digital signature. Standardized as RFC 7519 in 2015, it is widely used as an OAuth 2.0 access token and as an assertion for single sign-on (SSO). Its greatest characteristic is enabling stateless authentication that does not retain session information on the server side, and its adoption expanded rapidly along with the spread of microservices architecture.
3-Part Structure - Header.Payload.Signature
A JWT consists of three parts separated by dots (.). Each part is Base64URL-encoded and cannot be read directly by humans, but once decoded the contents can be inspected as JSON.
The Difference Between JWS and JWE
The term JWT is commonly used to mean a "signed token," but in the specification there are two types: JWS (JSON Web Signature) and JWE (JSON Web Encryption).
The payload is merely Base64URL-encoded, so anyone can read its contents by decoding it. The signature makes it possible to detect tampering, but it cannot keep the contents confidential. The vast majority of what is generally called a "JWT" is this JWS format.
The payload itself is encrypted, so only those who hold the decryption key can read its contents. It takes a 5-part structure (Header, Encrypted Key, IV, Ciphertext, Authentication Tag). It is used when confidential information must be included in the token.
In practice, JWS is used far more often. The premise is that no personal or confidential data is included in the payload; if such data must be included, you should consider JWE or, better yet, revise the design so that it is not included in the token at all.
Benefits and Risks of Stateless Authentication
With stateless authentication using JWTs, the server does not retain session information. Because authentication is completed simply by verifying the token signature, there is no need to manage session tokens in Redis or a database, making horizontal scaling easy.
| Aspect | JWT (stateless) | Cookie session (stateful) |
|---|---|---|
| Server-side state | None (the token itself carries the information) | Present (a session store is required) |
| Scalability | High (verifiable on any server) | A session-sharing mechanism is required |
| Immediate revocation | Difficult (a blacklist scheme is required) | Easy (simply delete the session) |
| Token size | Large (hundreds of bytes to several KB) | Small (only the session ID) |
| CSRF resistance | Resistant when using the Authorization header | Countermeasures such as the SameSite attribute are required |
The greatest risk is that "a JWT, once issued, cannot be revoked immediately." Even if a user changes their password, a leaked JWT can continue to be used until it expires. To mitigate this problem, a common pattern is to set a short expiration for the access token (around 15 minutes) and reissue it with a refresh token. For requirements where immediate revocation is mandatory, you should either maintain a blacklist on the server side or choose cookie-based session management.
Representative Attacks That Target JWTs
An attack that rewrites the alg field in the Header to "none" to bypass signature verification. Many early libraries had implementations that accepted alg:none. As a countermeasure, explicitly whitelist the algorithms permitted on the server side.
An attack that rewrites the alg of a token signed with RS256 (asymmetric key) to HS256 (symmetric key) and uses the public key as the HMAC secret key. Because the public key is available to anyone, an attacker can generate a valid signature.
If the HS256 secret key is a short string or a guessable value, the key can be identified by brute force. It is essential to use a random key of at least 256 bits and to rotate it regularly.
The techniques of session hijacking apply to JWTs as well. It is important to understand them together with the fundamentals of encryption. Please also refer to countermeasures against session hijacking, defenses against session token theft, and best practices for API key management.Web authentication books on Amazon is recommended for systematic learning.
Was this article helpful?