JWT token creation in FastAPI - 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 proves who you are. It contains information like your user ID and is signed so others can trust it. This token is used to let users access protected parts of a website or app without logging in every time. It is a safe way to share identity and permissions between a client and a server.

Why it matters

Without JWT tokens, websites would need to check your username and password every time you do something, which is slow and risky. JWT tokens let servers trust users quickly and safely, improving speed and security. They also allow apps to work across different servers or services without sharing passwords. Without JWT, user sessions would be clunky and less secure, making online experiences worse.

Where it fits

Before learning JWT token creation, you should understand HTTP basics, how web servers and clients communicate, and basic Python programming. After JWT tokens, you can learn about OAuth, advanced security practices, and how to build full authentication systems in FastAPI or other frameworks.

Mental Model

Core Idea

A JWT token is a secure, signed package of user info that servers use to quickly verify identity without storing session data.

Think of it like...

Imagine a sealed envelope with your ID and permissions inside, stamped by a trusted official. Anyone who sees the envelope can trust what's inside without opening it because of the official stamp.

┌───────────────┐
│ JWT Token     │
├───────────────┤
│ Header        │  ← describes token type and signing method
├───────────────┤
│ Payload       │  ← contains user info and claims
├───────────────┤
│ Signature     │  ← verifies token authenticity
└───────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding JWT Token Structure

Concept: Learn the three parts that make up a JWT token: header, payload, and signature.

A JWT token has three parts separated by dots: header, payload, and signature. The header tells what type of token it is and how it is signed. The payload contains user data like user ID or roles. The signature is created by combining the header and payload with a secret key to ensure no one changed the token.

Result

You can recognize a JWT token as three base64 strings separated by dots, each part serving a clear role.

Understanding the token's parts helps you see how JWTs carry data securely and why each part is important.

2

Foundation

Basics of Token Signing

Concept: Learn how signing a token with a secret key ensures it cannot be tampered with.

Signing means creating a special code (signature) from the header and payload using a secret key. This signature is like a lock that only the server can open. If someone changes the token, the signature won't match, so the server knows it's fake.

Result

Tokens signed with a secret key can be trusted by the server to be unchanged and authentic.

Knowing how signing works is key to trusting tokens and preventing attackers from faking user identity.

3

Intermediate

Creating JWT Tokens in FastAPI

🤔Before reading on: do you think JWT tokens are created manually by combining strings or by using libraries? Commit to your answer.

Concept: Use Python libraries to create JWT tokens easily and correctly in FastAPI.

FastAPI uses the PyJWT library to create tokens. You write a function that takes user info, creates a payload with expiration time, and calls jwt.encode() with a secret key and algorithm. This returns a token string you can send to users.

Result

You get a ready-to-use JWT token string that clients can use to prove their identity.

Using libraries avoids mistakes and ensures tokens are created securely and follow standards.

4

Intermediate

Adding Expiration to Tokens

🤔Before reading on: do you think JWT tokens last forever or can they expire? Commit to your answer.

Concept: Include an expiration time in the token payload to limit how long the token is valid.

Add a claim called 'exp' to the payload with a timestamp in the future. When the server checks the token, it rejects it if expired. This protects users if tokens are stolen or lost.

Result

Tokens automatically become invalid after a set time, improving security.

Expiration limits damage from stolen tokens and forces users to re-authenticate periodically.

5

Advanced

Secure Secret Management

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

Concept: Keep the secret key used for signing tokens safe and separate from code.

Store the secret key in environment variables or secure vaults, not in code files. This prevents attackers from stealing the key if code is leaked. Rotate keys periodically and use strong random strings.

Result

Your tokens remain secure because only your server knows the secret key.

Protecting the secret key is critical; if leaked, attackers can create fake tokens.

6

Expert

Handling Token Revocation and Refresh

🤔Before reading on: do you think JWT tokens can be revoked instantly or only expire naturally? Commit to your answer.

Concept: Implement ways to revoke tokens before expiration and refresh tokens securely.

JWTs are stateless, so servers don't store them. To revoke, keep a blacklist of tokens or use short expiration with refresh tokens. Refresh tokens are long-lived and used to get new JWTs. This balances security and usability.

Result

Users can be logged out instantly, and tokens stay secure without storing sessions.

Knowing how to revoke and refresh tokens solves the main limitation of JWT's statelessness in real apps.

Under the Hood

JWT tokens are base64-encoded JSON objects split into header, payload, and signature. The signature is created by hashing the header and payload with a secret key using algorithms like HMAC SHA256. When a server receives a token, it decodes the header and payload, recalculates the signature with its secret key, and compares it to the token's signature. If they match and the token is not expired, the token is valid. This process requires no server-side session storage, making JWT stateless.

Why designed this way?

JWT was designed to allow secure, stateless authentication across distributed systems without needing a central session store. This reduces server load and allows easy scaling. The use of JSON makes tokens easy to read and extend. Signing ensures token integrity and authenticity. Alternatives like server sessions require storing user data on the server, which is harder to scale and maintain.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Header JSON   │──────▶│ Base64 Encode │──────▶│ Encoded Header│
└───────────────┘       └───────────────┘       └───────────────┘

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Payload JSON  │──────▶│ Base64 Encode │──────▶│ Encoded Payload│
└───────────────┘       └───────────────┘       └───────────────┘

┌───────────────────────────────┐
│ Signature = HMACSHA256(secret, │
│ EncodedHeader + '.' + EncodedPayload) │
└───────────────────────────────┘

Encoded JWT = EncodedHeader + '.' + EncodedPayload + '.' + Signature

Myth Busters - 4 Common Misconceptions

Quick: Do you think JWT tokens are encrypted by default? Commit to yes or no.

Common Belief: JWT tokens are encrypted, so no one can read their contents.

Reality: JWT tokens are only signed, not encrypted. Anyone with the token can decode and read the payload data.

Why it matters: Assuming tokens are secret can lead to exposing sensitive info in the payload, risking user privacy.

Quick: Can JWT tokens be invalidated instantly by the server? Commit to yes or no.

Common Belief: JWT tokens can be revoked instantly like server sessions.

Reality: JWT tokens are stateless and cannot be revoked instantly unless extra measures like blacklists are used.

Why it matters: Not knowing this can cause security holes where stolen tokens remain valid until expiration.

Quick: Do you think the secret key can be shared with clients? Commit to yes or no.

Common Belief: The secret key used to sign JWT tokens can be shared with clients for verification.

Reality: The secret key must remain private on the server; clients only get the token, not the key.

Why it matters: Sharing the secret key breaks security, allowing attackers to forge tokens.

Quick: Is it safe to put passwords inside JWT payloads? Commit to yes or no.

Common Belief: It's fine to include passwords or sensitive secrets inside JWT payloads.

Reality: Sensitive data like passwords should never be inside JWT payloads because tokens are readable by anyone holding them.

Why it matters: Exposing passwords in tokens risks account compromise if tokens leak.

Expert Zone

1

JWT tokens can include custom claims beyond standard ones, but overloading payloads can increase token size and risk exposure.

2

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

3

Clock skew between client and server can cause valid tokens to be rejected; allowing small time leeway improves reliability.

When NOT to use

Avoid JWT tokens when you need immediate token revocation or store sensitive session data server-side. Use traditional server sessions or opaque tokens stored in databases instead.

Production Patterns

In production, JWT tokens are often short-lived with refresh tokens for usability. Secrets are stored securely in environment variables. Tokens are sent in HTTP headers with Bearer scheme. Middleware verifies tokens on each request to protect routes.

Connections

OAuth 2.0

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

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

Public Key Cryptography

JWT can use asymmetric signing algorithms that rely on public/private key pairs.

Knowing public key cryptography clarifies how JWTs can be verified by anyone with the public key but only signed by the private key holder.

Digital Certificates

JWT signatures and digital certificates both use cryptographic signatures to prove authenticity.

Recognizing this connection helps understand trust models in web security beyond just tokens.

Common Pitfalls

#1 Hardcoding the secret key in source code.

Wrong approach:

SECRET_KEY = "mysecret123" # directly in code

Correct approach:

import os
SECRET_KEY = os.getenv('SECRET_KEY') # loaded from environment

Root cause:

Beginners often put secrets in code for convenience, not realizing it risks exposure if code is shared.

#2 Not setting token expiration, creating tokens that never expire.

Wrong approach:

payload = {"user_id": 1}
token = jwt.encode(payload, SECRET_KEY, algorithm="HS256")

Correct approach:

from datetime import datetime, timedelta
payload = {"user_id": 1, "exp": datetime.utcnow() + timedelta(minutes=30)}
token = jwt.encode(payload, SECRET_KEY, algorithm="HS256")

Root cause:

Beginners forget to add expiration, leaving tokens valid forever and increasing security risk.

#3 Including sensitive info like passwords in the token payload.

Wrong approach:

payload = {"user_id": 1, "password": "mypassword"}

Correct approach:

payload = {"user_id": 1}

Root cause:

Misunderstanding that JWT payloads are readable by anyone with the token.

Key Takeaways

JWT tokens are secure, signed packages of user info that servers use to verify identity without storing sessions.

Tokens have three parts: header, payload, and signature; the signature ensures the token is authentic and unchanged.

Creating JWT tokens in FastAPI is done using libraries like PyJWT, which handle encoding and signing safely.

Always include expiration in tokens and keep the secret key secure to prevent misuse and attacks.

JWT tokens are stateless and cannot be revoked instantly without extra measures, so plan token lifetimes and refresh strategies carefully.

Practice

1. What is the main purpose of creating a JWT token in FastAPI?

easy

A. To style the user interface

B. To send emails automatically

C. To connect to a database

D. To securely store user information for authentication

Solution

1. Step 1: Understand JWT token purpose

   JWT tokens are used to safely carry user data for authentication.

2. Step 2: Identify correct use in FastAPI

   FastAPI uses JWT tokens to verify user identity securely.

3. Final Answer:

   To securely store user information for authentication -> Option D

4. Quick Check:

   JWT purpose = secure user info [OK]

Hint: JWT tokens are for secure user identity, not UI or DB [OK]

Common Mistakes:

• Confusing JWT with UI styling or database connection
• Thinking JWT sends emails
• Assuming JWT stores passwords directly

2. Which of the following is the correct way to import the function to create JWT tokens in FastAPI using PyJWT?

easy

A. import jwt.encode

B. from fastapi import jwt_encode

C. from jwt import encode

D. from fastapi.security import create_jwt

Solution

1. Step 1: Identify the JWT library used

   PyJWT is commonly used and provides an encode function imported as 'from jwt import encode'.

2. Step 2: Check FastAPI imports

   FastAPI itself does not provide jwt_encode or create_jwt functions directly.

3. Final Answer:

   from jwt import encode -> Option C

4. Quick Check:

   PyJWT encode import = from jwt import encode [OK]

Hint: PyJWT encode is imported from jwt, not fastapi [OK]

Common Mistakes:

• Trying to import JWT functions directly from FastAPI
• Using incorrect import syntax
• Confusing module names

3. Given this code snippet, what will be the output of the print(token) statement?

from jwt import encode

payload = {"user_id": 123}
secret = "mysecret"
algorithm = "HS256"
token = encode(payload, secret, algorithm=algorithm)
print(token)

medium

A. A JWT token string encoded with user_id 123

B. An error because algorithm parameter is missing

C. The original payload dictionary printed

D. None, because encode returns nothing

Solution

1. Step 1: Understand encode function behavior

   The encode function creates a JWT token string from the payload using the secret and algorithm.

2. Step 2: Analyze the code snippet

   Payload and secret are provided correctly, algorithm is set to HS256, so encode returns a JWT token string.

3. Final Answer:

   A JWT token string encoded with user_id 123 -> Option A

4. Quick Check:

   encode returns JWT string [OK]

Hint: encode returns a token string, not the original data [OK]

Common Mistakes:

• Expecting encode to print the payload
• Missing algorithm causes error (not true here)
• Thinking encode returns None

4. Identify the error in this JWT token creation code snippet:

from jwt import encode

payload = {"user_id": 42}
secret = "secretkey"
token = encode(payload, secret)
print(token)

medium

A. Missing algorithm parameter causes an error

B. No error; code runs correctly

C. Secret key should be bytes, not string

D. Payload must be a string, not a dictionary

Solution

1. Step 1: Check encode function requirements

   PyJWT's encode has a default algorithm='HS256', so it is not strictly required.

2. Step 2: Analyze the code snippet

   The code calls encode with payload and secret; algorithm defaults to HS256, so it runs correctly and produces a token.

3. Final Answer:

   No error; code runs correctly -> Option B

4. Quick Check:

   Algorithm defaults to HS256 = no error [OK]

Hint: PyJWT encode defaults to HS256 algorithm [OK]

Common Mistakes:

• Assuming algorithm defaults to HS256
• Thinking payload must be string
• Believing secret must be bytes

5. You want to create a JWT token in FastAPI that expires in 30 minutes. Which code snippet correctly adds the expiration time to the payload before encoding?

hard

A. payload = {"user_id": 1, "exp": datetime.utcnow() + timedelta(minutes=30)}

B. payload = {"user_id": 1, "exp": str(datetime.utcnow() + timedelta(minutes=30))}

C. payload = {"user_id": 1, "exp": time.time() + 1800}

D. payload = {"user_id": 1, "exp": datetime.now() + timedelta(minutes=30)}

Solution

1. Step 1: Understand JWT expiration format

   The 'exp' claim must be a UTC datetime or a timestamp representing expiration time.

2. Step 2: Evaluate each option

   payload = {"user_id": 1, "exp": datetime.utcnow() + timedelta(minutes=30)} uses datetime.utcnow() + timedelta for 30 minutes, which is correct. payload = {"user_id": 1, "exp": str(datetime.utcnow() + timedelta(minutes=30))} converts datetime to string, which is invalid. payload = {"user_id": 1, "exp": time.time() + 1800} uses time.time() but JWT expects datetime or timestamp as int, so this may cause issues. payload = {"user_id": 1, "exp": datetime.now() + timedelta(minutes=30)} uses datetime.now() which is local time, not UTC, causing potential errors.

3. Final Answer:

   payload = {"user_id": 1, "exp": datetime.utcnow() + timedelta(minutes=30)} -> Option A

4. Quick Check:

   Use UTC datetime for 'exp' claim [OK]

Hint: Use datetime.utcnow() + timedelta for expiration [OK]

Common Mistakes:

• Using local time instead of UTC
• Converting datetime to string for 'exp'
• Using wrong time functions like time.time() without conversion