Python FastAPI Tutorial (Part 11): Authorization - Protecting Routes and Verifying Current User

Authorization becomes real only after the API stops trusting client-supplied user IDs. This tutorial turns a working JWT login system into route protection by introducing a reusable “current user” dependency that validates the token, loads the user from the database, and injects the authenticated user into any endpoint that needs it. The payoff is immediate: post creation no longer lets clients impersonate other users, and edit/delete operations gain strict ownership rules.

The starting point is a security gap. The post creation schema still accepts a user_id from the request body, and the front end uses hard-coded user IDs. That means anyone can create, edit, or delete posts for any account simply by changing IDs. The fix is to remove user_id from the client payload and instead derive it from the trusted JWT. A new dependency is built by combining existing pieces: an OAuth2 token extractor that reads the Authorization header and a verify_access_token function that checks validity and returns a user identifier. The dependency then converts the token’s user ID to an integer, queries the database for the corresponding user, and raises a 401 Unauthorized when the token is missing/invalid/expired or when the user no longer exists.

To make this ergonomic, the tutorial defines a type alias (current user) using FastAPI’s annotated dependency pattern. Routes can then declare current user as a parameter, and FastAPI automatically enforces authentication before the endpoint logic runs. With that in place, the postcreate schema drops the user_id field entirely, and the post creation endpoint assigns post.user_id from current_user.id. The code also shrinks because the manual “verify user exists” logic is no longer needed.

Ownership checks tighten the remaining holes. For update and delete endpoints, the tutorial adds the current user dependency and then compares the post’s stored owner ID to current_user.id. If they don’t match, the API returns 403 Forbidden with a clear “not authorized” message—distinguishing “not authenticated” (401) from “authenticated but not permitted” (403). The same pattern is applied to user profile update and user deletion, ensuring users can only modify or remove their own accounts.

A major usability upgrade follows on the front end. API calls now include the Authorization: Bearer <token> header, and client-side handlers redirect to login on 401. Edit/delete buttons on post pages are hidden unless the logged-in user owns the post, with JavaScript performing the ownership comparison after fetching the current user. The tutorial also adds an account page that fetches the current user via the /me endpoint and supports profile updates and account deletion. Importantly, the account page itself isn’t server-protected because the server can’t read localStorage tokens during template rendering; real security still lives in the API, where missing/invalid tokens trigger 401 and ownership mismatches trigger 403.

End-to-end testing confirms the behavior: unauthenticated requests to protected routes fail, posts created by one user can’t be edited or deleted by another, and deleting an account removes that user’s posts. The result is a production-style authorization layer built directly on top of JWT authentication—no more hard-coded IDs, and no more client-controlled identity.