What JWT is and how it works
A JWT consists of three parts: header, payload and signature. The header contains information about the token type and signing algorithm. The payload stores user data and metadata. The signature is a cryptographic signature computed with a key to verify the authenticity of the token.
In Sayt.uz practice, JWT is mainly used for API authentication and stateless sessions. The token is stored on the client side and sent with every request via the Authorization header. The server validates the token and determines the user permissions.
Choosing the signing algorithm
JWT supports several signing algorithms: HS256, HS512, RS256, ES256 and others. HS256 is a symmetric algorithm where the same secret key is used for signing and verification. RS256 is asymmetric โ signing is done with a private key and verification with a public key.
In Sayt.uz practice, RS256 is recommended for microservice architectures because multiple services can verify a token using the public key, while the signing capability remains with one service. For monolithic applications HS256 is sufficient and works faster.
Secret rotation and key management
The secret key is not a simple password but a random value at least 256 bits long. Never store it in code; load it via environment variable or a secret manager (HashiCorp Vault, AWS Secrets Manager). It is recommended to rotate the key every 90 days.
To prevent tokens signed with the old key from breaking immediately during rotation, key versioning is used. A kid (key ID) field is stored in the token header, and the server keeps several keys, choosing the right one by kid. The old key is safely removed after all its tokens expire.
Expiration and refresh tokens
Access token lifetime should be short, typically 15 minutes to 1 hour. This limits damage from a stolen token. To avoid forcing users to log in every 15 minutes, a refresh token mechanism is used. Refresh tokens live longer (7-30 days) and are only used to obtain a new access token.
In Sayt.uz practice the refresh token is stored as an httpOnly cookie, which protects against XSS attacks. With every refresh the old token is revoked and a new one issued (rotation). If a revoked token is reused, it is a theft signal and all sessions are forcibly closed.
Common attacks
The most famous attack is the none algorithm: the attacker changes the alg field in the header to none and sends an unsigned token. Old JWT libraries accepted this. Modern versions are protected, but always keep the library updated and enforce an algorithm whitelist rule.
Another issue is algorithm confusion: if the server accepts both RS256 and HS256, an attacker can use the public key as the HS256 secret and forge a token. The solution is to fix exactly one algorithm per endpoint. To reduce brute force risk the secret key must be long and random.
Sayt.uz practice
At Sayt.uz the JWT configuration is as follows: access token 30 minutes, refresh token 7 days, signing algorithm RS256, secret key in AWS Secrets Manager, rotation every 90 days. Each failed verification is logged, and on anomaly detection the administrator is notified. Token blacklist is stored in Redis and populated immediately on logout.