FastAPI Authentication: The Complete Guide to JWT & OAuth2 (2026)

If you’ve built your first FastAPI app, connected it to a database, and started thinking “okay, now how do I stop anyone from hitting my endpoints” — you’ve hit the wall almost every FastAPI developer hits. Authentication is the single most-searched FastAPI topic after “what is FastAPI” itself, and for good reason: get it wrong, and you don’t have a bug, you have a breach.

This guide walks through exactly how to implement JWT and OAuth2 authentication in FastAPI, the differences between the two, and the mistakes that quietly leave production APIs exposed.

If you haven’t yet read our guide on what FastAPI is and why developers prefer it, start there. If you’re connecting FastAPI to a database, our FastAPI + PostgreSQL integration guide is the natural companion to this one. This post picks up right where those leave off: your API works, your data is connected — now let’s lock the door.

Why Authentication Is Where Most FastAPI Projects Go Wrong

FastAPI makes it deceptively easy to ship an endpoint. It does not make security automatic. Every endpoint you create is publicly reachable by default unless you explicitly protect it. Teams under deadline pressure routinely ship APIs with:

• No token expiry (a stolen token works forever)
• Passwords stored in plain text or with weak hashing
• Secrets hardcoded directly in source files
• No distinction between access tokens and refresh tokens

None of these show up in a demo. All of them show up in an incident report. The good news: FastAPI’s dependency injection system makes it one of the cleanest frameworks to secure properly — once you know the pattern.

JWT vs OAuth2 vs API Keys vs Sessions: What’s the Difference?

These terms get used interchangeably, but they solve different problems. Here’s the breakdown:

Method

What It Actually Is

Best For

Watch Out For

Session-based auth

Server stores session state, browser holds a cookie

Traditional server-rendered apps

Doesn’t scale well across stateless/distributed APIs

API Keys

A static secret string sent with each request

Server-to-server, internal tools

No expiry by default, hard to revoke individually

JWT (JSON Web Token)

A signed, self-contained token holding user claims

Stateless APIs, mobile/SPA backends

Can’t be revoked early without extra infrastructure

OAuth2

A framework for delegated authorization (often issuing JWTs underneath)

“Login with Google,” third-party access, granular scopes

Frequently implemented incorrectly — it’s a protocol, not a single line of code

The short version for most FastAPI projects: you’ll use OAuth2’s password flow to collect credentials, and JWT as the token format it issues. They’re not competitors — OAuth2 is the delivery mechanism, JWT is what gets delivered.

Step 1: Setting Up Password Hashing

Never store plain-text passwords. Ever. FastAPI’s ecosystem leans on passlib with the bcrypt algorithm:

pip install passlib[bcrypt] python-jose[cryptography] python-multipart

from passlib.context import CryptContext

pwd_context = CryptContext(schemes=[“bcrypt”], deprecated=”auto”)

def hash_password(password: str) -> str:

return pwd_context.hash(password)

def verify_password(plain_password: str, hashed_password: str) -> bool:

return pwd_context.verify(plain_password, hashed_password)

Store only the output of hash_password() in your database. Never the raw password, never reversibly encrypted — hashed.

Step 2: Creating and Verifying JWTs

from datetime import datetime, timedelta, timezone

from jose import jwt, JWTError

SECRET_KEY = “your-secret-key-from-env-not-hardcoded”

ALGORITHM = “HS256”

ACCESS_TOKEN_EXPIRE_MINUTES = 30

def create_access_token(data: dict, expires_delta: timedelta | None = None):

to_encode = data.copy()

expire = datetime.now(timezone.utc) + (expires_delta or timedelta(minutes=ACCESS_TOKEN_EXPIRE_MINUTES))

to_encode.update({“exp”: expire})

return jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)

def decode_access_token(token: str):

try:

return jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])

except JWTError:

return None

A critical detail teams miss: SECRET_KEY must live in an environment variable, not in your codebase. If it’s in your Git history, it’s compromised the moment that repo is shared, forked, or leaked.

Step 3: Building the Login Endpoint with OAuth2PasswordBearer

from fastapi import FastAPI, Depends, HTTPException, status

from fastapi.security import OAuth2PasswordBearer, OAuth2PasswordRequestForm

app = FastAPI()

oauth2_scheme = OAuth2PasswordBearer(tokenUrl=”token”)

@app.post(“/token”)

async def login(form_data: OAuth2PasswordRequestForm = Depends()):

user = get_user_from_db(form_data.username) # your DB lookup

if not user or not verify_password(form_data.password, user.hashed_password):

raise HTTPException(

status_code=status.HTTP_401_UNAUTHORIZED,

detail=”Incorrect username or password”,

headers={“WWW-Authenticate”: “Bearer”},

)

access_token = create_access_token(data={“sub”: user.username})

return {“access_token”: access_token, “token_type”: “bearer”}

OAuth2PasswordBearer isn’t just decoration — it’s what tells FastAPI’s auto-generated docs (/docs) to show the “Authorize” button, and it’s what extracts the bearer token from incoming request headers automatically.

Step 4: Protecting Routes

This is where FastAPI’s dependency injection shines — securing an endpoint is a one-line addition:

async def get_current_user(token: str = Depends(oauth2_scheme)):

payload = decode_access_token(token)

if payload is None:

raise HTTPException(status_code=401, detail=”Invalid or expired token”)

user = get_user_from_db(payload.get(“sub”))

if user is None:

raise HTTPException(status_code=401, detail=”User not found”)

return user

@app.get(“/profile”)

async def read_profile(current_user = Depends(get_current_user)):

return {“username”: current_user.username}

Add Depends(get_current_user) to any route, and it’s instantly protected — no token, no access, no exceptions.

Step 5: Adding Refresh Tokens (Don’t Skip This)

Short-lived access tokens (15–30 minutes) are good security practice — but forcing users to log in every 15 minutes is a terrible product experience. The fix is a refresh token: long-lived, stored securely (often as an HTTP-only cookie), used only to mint new access tokens.

REFRESH_TOKEN_EXPIRE_DAYS = 7

def create_refresh_token(data: dict):

to_encode = data.copy()

expire = datetime.now(timezone.utc) + timedelta(days=REFRESH_TOKEN_EXPIRE_DAYS)

to_encode.update({“exp”: expire, “type”: “refresh”})

return jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)

On your /token/refresh endpoint, verify the refresh token, confirm it’s actually flagged as a refresh token (not an access token someone is trying to reuse), and issue a fresh access token. This single pattern — access token + refresh token — is what separates a tutorial project from a production-ready one.

Going Further: OAuth2 with Third-Party Providers

Everything above covers OAuth2’s password flow, where your own API issues tokens. If you want “Login with Google” or “Login with GitHub,” you’re implementing OAuth2’s authorization code flow instead — the user authenticates with the provider, the provider redirects back with a code, and your backend exchanges that code for tokens. Libraries like Authlib or fastapi-users handle most of this plumbing so you’re not building an OAuth2 client from scratch.

This is also where complexity — and risk — climbs fastest. Token exchange, state parameter validation (to prevent CSRF), and redirect URI whitelisting all need to be correct, not just functional. It’s the part of auth implementation where teams most often bring in outside expertise rather than reinvent it under deadline.

Common Mistakes That Undermine FastAPI Authentication

• Storing JWT secrets in code instead of environment variables or a secrets manager
• No token expiry, or expiry set so long it defeats the purpose
• Treating JWTs as revocable — by design, a JWT is valid until it expires; if you need instant revocation (e.g., on logout or compromise), you need a token blocklist or short expiry + refresh rotation
• Skipping HTTPS — a JWT sent over plain HTTP is a JWT handed to anyone listening on the network
• Weak or reused SECRET_KEY values across environments (dev, staging, prod should never share one)
• No rate limiting on /token, leaving the login endpoint open to brute-force attempts

Testing Your Authentication

A quick sanity check before shipping:

from fastapi.testclient import TestClient

client = TestClient(app)

def test_protected_route_requires_token():

response = client.get(“/profile”)

assert response.status_code == 401

def test_login_and_access():

login_response = client.post(“/token”, data={“username”: “test”, “password”: “test123”})

token = login_response.json()[“access_token”]

response = client.get(“/profile”, headers={“Authorization”: f”Bearer {token}”})

assert response.status_code == 200

If these two pass, your core auth flow is functioning. Production hardening — rate limiting, refresh rotation, monitoring failed login attempts — is a separate layer on top.

When to Bring In a FastAPI Team Instead of DIY-ing It

Everything in this guide is genuinely implementable by a competent developer in an afternoon. Where teams run into trouble isn’t the happy path — it’s the edges: token revocation at scale, integrating OAuth2 with multiple third-party providers, role-based access control layered on top of authentication, and security audits before a client or investor asks “how is this protected?”

At Drish Infotech, our Python and FastAPI development team builds and audits authentication systems for production APIs — not tutorial projects. If you’re scaling past your MVP, integrating SSO, or just want a second pair of eyes on what you’ve already built, that’s exactly the kind of work we do daily.

**Talk to our FastAPI development team →**

FAQs

Is JWT the same as OAuth2? No. OAuth2 is an authorization framework — a set of rules for how tokens get issued and used. JWT is a token format. In most FastAPI apps, OAuth2’s password flow is used to authenticate users, and JWT is the format of the token it returns.

How long should a JWT access token last? 15–30 minutes is a common production standard, paired with a longer-lived refresh token (days to weeks) so users aren’t repeatedly logging in.

Can I revoke a JWT before it expires? Not natively — that’s a known JWT limitation. To support early revocation (e.g., on logout or a compromised account), you need an additional layer like a token blocklist stored in Redis, or you keep access token lifetimes very short.

Is python-jose still the right library for JWT in FastAPI in 2026? It remains widely used and is what FastAPI’s official documentation references, though PyJWT is a solid, actively maintained alternative if you prefer a smaller dependency footprint.

Do I need OAuth2 if I’m only building an internal API? Not necessarily. For server-to-server internal tools, a simple API key or service-to-service JWT is often simpler and sufficient. OAuth2’s real value shows up with user-facing apps and third-party logins.

Conclusion

Authentication isn’t a checkbox — it’s the difference between an API that’s ready for real users and one that’s a headline waiting to happen. FastAPI gives you the tools to do this properly with surprisingly little boilerplate: hash passwords correctly, issue short-lived JWTs through OAuth2’s password flow, protect routes with Depends, and add refresh tokens before you ship.

If you’re building something that needs to be production-grade rather than demo-grade, that’s where having an experienced team matters.

**Get in touch with Drish Infotech →**