How JWT works
A JWT has three Base64-encoded parts separated by dots: a header describing the algorithm, a payload of claims such as subject and expiry, and a signature. The issuer signs the token with a secret or private key, and receivers verify the signature and check claims before trusting it.
Because the payload is encoded rather than encrypted by default, anyone holding the token can read it. Tokens are normally sent in an authorization header and are valid until they expire, which makes lifetime, storage and revocation design important. Algorithm confusion attacks occur when a server accepts a token signed with an unexpected algorithm, which is why the accepted algorithms should be fixed on the server side.
Why it matters for Canadian organizations
JWTs are widely used in modern applications, so implementation mistakes affect many systems. Common flaws include accepting unsigned tokens, trusting the algorithm named in the header, weak signing secrets, missing expiry checks and storing tokens where scripts can steal them.
A stolen token can let an attacker act as the user until it expires. For applications that handle personal information, token weaknesses can lead to exposure that engages PIPEDA and Quebec Law 25 obligations. Revocation is difficult because tokens are validated without a lookup, so organizations use short lifetimes, deny lists for compromised tokens, or rotating refresh tokens.
How to defend against it
Use well-maintained libraries, enforce an allowed list of algorithms, and verify signature, issuer, audience and expiry on every request. Use strong keys and rotate them.
Keep access tokens short-lived, use refresh tokens with protection, and store tokens securely, for example in HttpOnly cookies for browser apps. Do not place sensitive data in the payload, and include token handling in code review and application security testing. Include token validation tests in your application security reviews, since small configuration mistakes can silently undermine the entire authentication scheme.
Frequently asked questions
Is a JWT encrypted?
Usually not. A standard signed JWT is encoded, so its contents can be read by anyone who has it, but the signature prevents undetected changes. If confidentiality is needed, use an encrypted variant or avoid putting sensitive data in claims.
What is the difference between a JWT and a session cookie?
A session cookie holds an identifier that the server looks up in stored session data. A JWT carries the claims itself and is verified by signature, which allows stateless checks. JWTs are harder to revoke before expiry unless extra mechanisms are added.
Where should a JWT be stored in a browser?
Options all carry tradeoffs. HttpOnly, Secure, SameSite cookies protect tokens from script access but need CSRF protection. Local storage is simple but exposes tokens to cross-site scripting. The best choice depends on the application's threat model.
Related service: Application security