Bird
Raised Fist0
FastAPIframework~30 mins

Protected routes in FastAPI - Mini Project: Build & Apply

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Protected Routes with FastAPI
📖 Scenario: You are building a simple web API using FastAPI. Some parts of your API should only be accessible to users who provide a secret token. This is like having a locked door that only opens if you have the right key.
🎯 Goal: Create a FastAPI app with one public route and one protected route. The protected route should only allow access if the request includes the correct secret token in the headers.
📋 What You'll Learn
Create a FastAPI app instance named app
Define a secret token string variable named SECRET_TOKEN with value "mysecrettoken"
Create a public route at /public that returns a welcome message
Create a protected route at /protected that checks for the header X-Token
If the X-Token header matches SECRET_TOKEN, return a success message
If the token is missing or incorrect, return a 401 Unauthorized error
💡 Why This Matters
🌍 Real World
Many web APIs need to protect certain routes so only authorized users can access them. This project shows a simple way to do that with FastAPI.
💼 Career
Understanding how to protect routes is essential for backend developers building secure APIs. This skill is commonly required in real-world web development jobs.
Progress0 / 4 steps
1
Create FastAPI app and secret token
Import FastAPI from fastapi. Create a FastAPI app instance called app. Then create a string variable called SECRET_TOKEN and set it to "mysecrettoken".
FastAPI
Hint

Remember to import FastAPI first. Then create the app and the secret token variable exactly as named.

2
Create a public route
Add a route to app using the decorator @app.get("/public"). Define a function called public_route that returns a dictionary with the key message and value "Welcome to the public route!".
FastAPI
Hint

Use the @app.get decorator with the path /public. The function should return the exact dictionary.

3
Add header parameter and check token
Import Header and HTTPException from fastapi. Create a route at /protected with @app.get("/protected"). Define a function called protected_route that takes a parameter x_token with type str | None and default Header(default=None, alias="X-Token"). Inside the function, check if x_token is not equal to SECRET_TOKEN. If so, raise HTTPException(status_code=401, detail="Unauthorized").
FastAPI
Hint

Use Header to read the X-Token header. Compare it to SECRET_TOKEN and raise HTTPException if it does not match.

4
Return success message from protected route
In the protected_route function, after the token check, return a dictionary with the key message and value "You have access to the protected route!".
FastAPI
Hint

Return the success message dictionary after the token check passes.

Practice

(1/5)
1. What is the main purpose of protected routes in FastAPI?
easy
A. To automatically generate API documentation
B. To speed up the API response time
C. To allow anyone to access all endpoints without restrictions
D. To restrict access to certain endpoints by verifying user credentials

Solution

  1. Step 1: Understand what protected routes do

    Protected routes limit access to certain parts of an app by checking if the user is allowed.
  2. Step 2: Identify the correct purpose

    Only To restrict access to certain endpoints by verifying user credentials describes restricting access by verifying user credentials, which matches protected routes.
  3. Final Answer:

    To restrict access to certain endpoints by verifying user credentials -> Option D
  4. Quick Check:

    Protected routes = restrict access [OK]
Hint: Protected routes check user access before allowing endpoint use [OK]
Common Mistakes:
  • Thinking protected routes improve speed
  • Confusing protected routes with documentation features
  • Assuming protected routes allow open access
2. Which FastAPI feature is commonly used to enforce protected routes by requiring token verification?
easy
A. BackgroundTasks
B. Depends
C. Query
D. Path

Solution

  1. Step 1: Recall FastAPI dependency injection

    FastAPI uses Depends to declare dependencies like authentication checks.
  2. Step 2: Match feature to protected routes

    Using Depends with a function that verifies tokens enforces protection on routes.
  3. Final Answer:

    Depends -> Option B
  4. Quick Check:

    Token check uses Depends [OK]
Hint: Use Depends to add token checks on routes [OK]
Common Mistakes:
  • Confusing Depends with query or path parameters
  • Using BackgroundTasks for authentication
  • Not using any dependency for protection
3. Given this FastAPI code snippet, what will happen when accessing /users/me without a token?
from fastapi import FastAPI, Depends, HTTPException
from fastapi.security import OAuth2PasswordBearer

app = FastAPI()
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")

def get_current_user(token: str = Depends(oauth2_scheme)):
    if token != "validtoken":
        raise HTTPException(status_code=401, detail="Invalid token")
    return {"username": "user1"}

@app.get("/users/me")
async def read_users_me(current_user: dict = Depends(get_current_user)):
    return current_user
medium
A. Raises HTTP 401 Unauthorized error
B. Returns {"username": "user1"} regardless of token
C. Returns an empty response
D. Raises HTTP 404 Not Found error

Solution

  1. Step 1: Analyze token dependency behavior

    The function get_current_user checks if the token equals "validtoken"; otherwise, it raises HTTP 401.
  2. Step 2: Consider no token case

    Without a token, oauth2_scheme will not provide a valid token, so the check fails and raises HTTP 401.
  3. Final Answer:

    Raises HTTP 401 Unauthorized error -> Option A
  4. Quick Check:

    No token = HTTP 401 error [OK]
Hint: No valid token triggers HTTP 401 error [OK]
Common Mistakes:
  • Assuming it returns user data without token
  • Confusing 401 with 404 error
  • Expecting empty response instead of error
4. Identify the error in this FastAPI protected route code:
from fastapi import FastAPI, Depends, HTTPException
from fastapi.security import OAuth2PasswordBearer

app = FastAPI()
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")

def get_current_user(token: str):
    if token != "secret":
        raise HTTPException(status_code=401, detail="Unauthorized")
    return {"user": "admin"}

@app.get("/dashboard")
async def dashboard(user: dict = Depends(get_current_user)):
    return user
medium
A. OAuth2PasswordBearer is not imported
B. HTTPException is not imported
C. Missing Depends in get_current_user parameter
D. Route path is invalid

Solution

  1. Step 1: Check get_current_user parameter

    The function expects token: str but does not use Depends(oauth2_scheme) to get the token automatically.
  2. Step 2: Identify missing dependency injection

    Without Depends(oauth2_scheme), FastAPI won't provide the token, causing an error.
  3. Final Answer:

    Missing Depends in get_current_user parameter -> Option C
  4. Quick Check:

    Token param needs Depends(oauth2_scheme) [OK]
Hint: Use Depends(oauth2_scheme) to get token in dependencies [OK]
Common Mistakes:
  • Forgetting to import HTTPException
  • Not using Depends for token parameter
  • Incorrect route path syntax
5. How can you combine FastAPI's OAuth2PasswordBearer with a custom user verification function to protect multiple routes efficiently?
hard
A. Create a reusable dependency function that uses OAuth2PasswordBearer to get the token and verifies the user, then use Depends on routes
B. Add token verification code inside each route handler separately
C. Use OAuth2PasswordBearer only in the main app instance without dependencies
D. Skip token verification and rely on client-side checks

Solution

  1. Step 1: Understand reusable dependency pattern

    Creating a function that uses OAuth2PasswordBearer to get the token and verifies the user allows reuse across routes.
  2. Step 2: Apply Depends to routes

    Using Depends with this function on multiple routes enforces protection without repeating code.
  3. Final Answer:

    Create a reusable dependency function that uses OAuth2PasswordBearer to get the token and verifies the user, then use Depends on routes -> Option A
  4. Quick Check:

    Reusable dependency + Depends = efficient protection [OK]
Hint: Make one verify function and reuse with Depends on routes [OK]
Common Mistakes:
  • Duplicating token checks in every route
  • Not using Depends for token verification
  • Ignoring server-side token checks