JWT token creation in Express - Deep Dive

Overview - JWT token creation

What is it?

JWT token creation is the process of making a secure string called a JSON Web Token that represents user identity or data. This token is digitally signed so it can be trusted and used to verify who a user is without storing session data on the server. It is commonly used in web applications to manage user login and permissions. The token contains encoded information and a signature to prevent tampering.

Why it matters

Without JWT tokens, servers would need to keep track of every user's login state, which is slow and hard to scale. JWT tokens let servers trust the token itself, making user authentication faster and easier across many servers or services. This improves user experience by allowing seamless access and reduces server load. Without JWT, many modern apps would struggle with performance and security.

Where it fits

Before learning JWT token creation, you should understand basic web servers, HTTP requests, and user authentication concepts. After mastering JWT tokens, you can learn about token verification, refresh tokens, and securing APIs with JWT. This topic fits into the broader journey of building secure, scalable web applications.

Mental Model

Core Idea

A JWT token is a secure, self-contained package of user data that servers can trust without storing session info.

Think of it like...

Imagine a sealed envelope with a signed letter inside. The letter says who you are and what you can do. The signature proves the letter is genuine and untampered. Anyone who sees the envelope can trust the letter without checking with the sender again.

┌───────────────┐
│ JWT Token     │
│───────────────│
│ Header        │
│ (algorithm,   │
│  token type)  │
├───────────────┤
│ Payload       │
│ (user data,   │
│  claims)      │
├───────────────┤
│ Signature     │
│ (signed hash) │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding JSON Web Tokens

Concept: Learn what a JWT is and its three parts: header, payload, and signature.

A JWT is a string made of three parts separated by dots: header, payload, and signature. The header tells which algorithm is used to sign the token. The payload contains user info or claims. The signature is created by combining the header and payload and signing them with a secret key. This signature ensures the token is trustworthy.

Result

You can identify the three parts of a JWT and understand their roles.

Understanding the structure of JWT is key to knowing how it securely carries user data without server storage.

2

Foundation

Installing JWT Library in Express

Concept: Set up the tools needed to create JWT tokens in an Express app.

Use npm to install the 'jsonwebtoken' package: npm install jsonwebtoken. This library provides functions to create and verify JWT tokens easily in Express. You also need Express installed to build the server that issues tokens.

Result

Your Express project is ready to create JWT tokens using the jsonwebtoken library.

Having the right tools installed is the first step to implementing JWT token creation practically.

3

Intermediate

Creating a JWT Token in Express

🤔Before reading on: Do you think the token is created by encrypting user data or by signing it? Commit to your answer.

Concept: Learn how to create a signed JWT token with user data in Express using the jsonwebtoken library.

In your Express route, import jsonwebtoken. Use jwt.sign(payload, secret, options) to create a token. The payload is an object with user info like userId. The secret is a private string only your server knows. Options can include token expiration time. The function returns a signed token string.

Result

You get a JWT token string that can be sent to the client for authentication.

Knowing that JWT tokens are signed, not encrypted, helps you understand why the payload is readable but protected from tampering.

4

Intermediate

Choosing Payload Data Wisely

🤔Before reading on: Should you put sensitive info like passwords inside the JWT payload? Commit to your answer.

Concept: Understand what kind of data should be included in the JWT payload for security and efficiency.

The payload should contain only non-sensitive info needed to identify the user, like user ID or roles. Avoid putting passwords or private data because the payload is base64 encoded and can be decoded by anyone. Keep the payload small to reduce token size and improve performance.

Result

Your tokens carry only safe, minimal data, reducing security risks and improving speed.

Knowing what to include in the payload prevents common security mistakes and keeps tokens efficient.

5

Intermediate

Setting Token Expiration Time

🤔Before reading on: Do you think JWT tokens should last forever or expire after some time? Commit to your answer.

Concept: Learn how to set an expiration time for JWT tokens to improve security.

When creating a token, pass an 'expiresIn' option like '1h' for one hour. This tells the token to become invalid after that time. Expiration limits the risk if a token is stolen. Clients must get a new token after expiration, usually by logging in again or using a refresh token.

Result

Tokens automatically expire, reducing the window for misuse.

Understanding token expiration is crucial for balancing user convenience and security.

6

Advanced

Using Environment Variables for Secrets

🤔Before reading on: Should the secret key be hardcoded in your code or stored securely? Commit to your answer.

Concept: Learn best practices for managing the secret key used to sign JWT tokens.

Never hardcode your secret key in source code. Instead, store it in environment variables or secure vaults. Access it in your Express app via process.env.JWT_SECRET. This prevents accidental exposure if code is shared or published. Rotate secrets periodically for extra security.

Result

Your app uses a secret key securely, protecting token integrity.

Knowing how to manage secrets properly prevents major security breaches in production.

7

Expert

Understanding JWT Token Vulnerabilities

🤔Before reading on: Do you think JWT tokens are completely secure and cannot be tampered with? Commit to your answer.

Concept: Explore common security pitfalls and how attackers might exploit JWT tokens if not used carefully.

JWT tokens are signed but not encrypted, so payload data is visible. Using weak secrets or none at all allows attackers to forge tokens. Accepting tokens without verifying signatures or ignoring expiration opens security holes. Also, algorithms like 'none' can be abused if your code doesn't check properly. Always validate tokens fully and use strong secrets.

Result

You understand the risks and how to avoid common JWT security mistakes.

Knowing JWT weaknesses helps you build safer authentication systems and avoid costly vulnerabilities.

Under the Hood

JWT creation involves encoding the header and payload as base64url strings, then creating a signature by hashing these with a secret key using a specified algorithm (like HMAC SHA256). The signature ensures the token's integrity. When a server receives a token, it recomputes the signature and compares it to the token's signature to verify authenticity. The payload is not encrypted, so it is readable but protected from tampering by the signature.

Why designed this way?

JWT was designed to be compact, URL-safe, and stateless, allowing easy transmission in HTTP headers or URLs. Signing instead of encrypting payloads balances security and performance, enabling servers to trust tokens without storing session data. Alternatives like server sessions require storage and don't scale well. JWT's design trades off confidentiality for simplicity and scalability, suitable for many web apps.

┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│ Header JSON   │      │ Payload JSON  │      │ Secret Key    │
└──────┬────────┘      └──────┬────────┘      └──────┬────────┘
       │                      │                      │
       ▼                      ▼                      │
┌───────────────┐      ┌───────────────┐            │
│ Base64Url     │      │ Base64Url     │            │
│ Encode Header │      │ Encode Payload│            │
└──────┬────────┘      └──────┬────────┘            │
       │                      │                      │
       └──────────────┬───────┴──────────────┬───────┘
                      ▼                      ▼
               ┌───────────────────────────────┐
               │ Concatenate with '.' separator │
               └──────────────┬────────────────┘
                              │
                              ▼
                    ┌─────────────────────┐
                    │ Create Signature by  │
                    │ hashing with secret  │
                    └────────────┬────────┘
                                 │
                                 ▼
                    ┌─────────────────────┐
                    │ Final JWT Token:     │
                    │ header.payload.sig   │
                    └─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think JWT tokens encrypt the user data inside them? Commit to yes or no.

Common Belief: JWT tokens encrypt all the user data so no one can read it except the server.

Reality: JWT tokens are only signed, not encrypted. The payload is base64 encoded, which anyone can decode and read.

Why it matters: Believing JWTs are encrypted can lead to putting sensitive data in the payload, exposing it to attackers.

Quick: Do you think a JWT token can be trusted forever once issued? Commit to yes or no.

Common Belief: Once a JWT token is created, it is valid forever unless manually revoked.

Reality: JWT tokens usually have expiration times and become invalid after that. They cannot be revoked easily without extra mechanisms.

Why it matters: Ignoring expiration can cause security risks if stolen tokens remain valid indefinitely.

Quick: Do you think the secret key used to sign JWTs can be shared publicly? Commit to yes or no.

Common Belief: The secret key is not very important and can be included in the code or shared.

Reality: The secret key must be kept private. If exposed, attackers can forge valid tokens.

Why it matters: Leaking the secret key compromises the entire authentication system.

Quick: Do you think you must always verify the JWT token's signature before trusting it? Commit to yes or no.

Common Belief: Sometimes you can trust the token without verifying the signature to save time.

Reality: Always verify the signature and expiration before trusting a JWT token.

Why it matters: Skipping verification allows attackers to use fake tokens and gain unauthorized access.

Expert Zone

1

Some JWT libraries allow algorithm switching attacks if the server blindly trusts the token's header algorithm field; always enforce expected algorithms.

2

Using asymmetric keys (RSA/ECDSA) for signing allows public verification without exposing the private key, improving security in distributed systems.

3

Refresh tokens are often used alongside JWTs to allow short-lived access tokens while maintaining user sessions without frequent logins.

When NOT to use

JWT tokens are not ideal when you need to revoke tokens instantly or store large user state server-side. In such cases, traditional server sessions or opaque tokens with a centralized store are better alternatives.

Production Patterns

In production, JWT tokens are issued after user login and sent in HTTP headers (Authorization: Bearer). Servers verify tokens on each request to protect APIs. Tokens are short-lived with refresh tokens to maintain sessions. Secrets are stored securely, and token algorithms are strictly enforced to prevent attacks.

Connections

OAuth 2.0

JWT tokens are often used as access tokens within OAuth 2.0 authorization flows.

Understanding JWT helps grasp how OAuth 2.0 securely delegates access without sharing passwords.

Digital Signatures

JWT signatures use cryptographic digital signatures to prove token authenticity.

Knowing digital signatures clarifies why JWT tokens cannot be tampered with without detection.

Passport Stamps

Like a passport stamp proves you passed a checkpoint, a JWT token proves you passed authentication.

This cross-domain link shows how tokens serve as trusted proof of identity in digital systems.

Common Pitfalls

#1 Including sensitive data like passwords in the JWT payload.

Wrong approach:

const token = jwt.sign({ userId: 123, password: 'secret' }, 'mysecret');

Correct approach:

const token = jwt.sign({ userId: 123 }, 'mysecret');

Root cause:

Misunderstanding that JWT payload is encrypted rather than just encoded.

#2 Hardcoding the secret key directly in source code.

Wrong approach:

const secret = 'mysecret'; // hardcoded
const token = jwt.sign(payload, secret);

Correct approach:

const secret = process.env.JWT_SECRET;
const token = jwt.sign(payload, secret);

Root cause:

Not knowing best practices for secret management and environment configuration.

#3 Not verifying the token signature before trusting it.

Wrong approach:

const decoded = jwt.decode(token); // no verification
console.log(decoded.userId);

Correct approach:

jwt.verify(token, secret, (err, decoded) => { if (err) throw err; console.log(decoded.userId); });

Root cause:

Confusing decoding (reading) with verifying authenticity and integrity.

Key Takeaways

JWT tokens are signed strings that securely carry user data without server-side session storage.

The token has three parts: header, payload, and signature; only the signature protects against tampering.

Always keep the secret key private and never put sensitive data in the payload since it is readable.

Set token expiration times to limit risks if tokens are stolen and always verify tokens before trusting.

JWT tokens improve scalability and performance but require careful handling to avoid security pitfalls.