Understanding Authentication in FastAPI
Before building a login system, understand what authentication is, why it exists, and how every request is verified.
Authentication is one of the first features added to most applications. Whether you’re building a blog, an e-commerce platform, a banking application, or a social media website, there comes a point where the application needs to answer a simple question:
Who is making this request?
At first glance, the answer seems obvious.
A user enters an email address and password, clicks the login button, and the application grants access.
Behind that seemingly simple interaction is an entire authentication system working together. Passwords are verified, identities are confirmed, security checks are performed, tokens are generated, and every future request is validated before the application allows access to protected resources.
Many tutorials skip directly to writing the login endpoint. Within a few minutes, a JWT is generated, routes are protected, and the authentication system appears to be complete.
The problem is that the code often becomes something developers copy rather than understand.
When a token expires unexpectedly, a protected route returns 401 Unauthorized, or a new authentication feature needs to be added, it becomes difficult to reason about what is happening because the underlying process was never explained.
This article takes a different approach.
Before implementing authentication in FastAPI, we’ll first understand how authentication works conceptually, why each component exists, and how the different pieces fit together. Once that foundation is clear, writing the actual implementation becomes much more intuitive.
Every Request Looks the Same
Imagine you’ve built a simple blogging API.
It has an endpoint that allows users to create new posts.
POST /postsNow suppose two different people send the exact same request.
The first request comes from Alice.
The second request comes from Bob.
Although the requests originate from different people, the server doesn’t automatically know that.
From the server’s perspective, both requests are simply HTTP messages arriving over the network.
An HTTP request contains information such as:
- the request method
- the requested URL
- request headers
- the request body
What it does not contain is a built-in way of identifying who sent it.
Unlike humans, servers cannot recognize names, faces, voices, or devices. Every request must explicitly provide enough information for the server to identify the client.
Without that information, every request is effectively anonymous.
This is the problem authentication exists to solve.
What Is Authentication?
Authentication is the process of verifying the identity of a user or client before allowing access to an application.
The important word here is verify.
A user isn’t considered authenticated simply because they claim to be someone.
If a login form contained only an email field, anyone could type another person’s email address and immediately gain access to that account.
The application needs evidence that the user really owns that identity.
Most applications use credentials such as an email address and password to provide that evidence.
When the submitted credentials match the information stored in the database, the server accepts the claim and treats the request as coming from that user.
At that point, the user’s identity has been authenticated.
Authentication doesn’t determine what the user is allowed to do.
It simply answers one question:
Who is making this request?
Everything else happens after that question has been answered.
Authentication vs Authorization
These two terms are often mentioned together because they work closely with one another.
Despite that, they solve completely different problems.
Authentication answers:
Who are you?
Authorization answers:
What are you allowed to do?
Imagine a project management application.
Get Ardy’s stories in your inbox
Join Medium for free to get updates from this writer.
A user logs in using their email address and password.
The application verifies the credentials and identifies the user.
Authentication is complete.
Now the same user attempts to delete another team’s project.
Before performing the deletion, the application checks whether that user has permission to manage the project.
That decision has nothing to do with identity anymore.
The application already knows who the user is.
Now it is deciding what that authenticated user is allowed to do.
That is authorization.
A simple way to remember the difference is this:
- Authentication identifies the user.
- Authorization determines the user’s permissions.
Authentication always comes first.
Without knowing who the user is, the application has no way to decide what resources they should be allowed to access.
The Journey of a Login Request
Let’s follow a user logging into an application.
The process is much more involved than entering a password and receiving access.
It begins when the user submits their credentials.
User
│
Email & Password
│
▼
FastAPI
The application receives the credentials and begins verifying them.
The supplied password is never compared directly against the password originally chosen by the user.
Instead, the stored password is a secure hash, which we’ll explore in detail in the next article.
If the credentials are valid, the application generates proof that the user has already authenticated successfully.
In modern APIs, that proof is usually a JSON Web Token (JWT).
The token is returned to the client.
At this point, something important changes.
The user no longer needs to send their email address and password with every request.
Instead, future requests include the JWT.
This makes authentication both secure and efficient.
The password is used only during login.
Every request after that relies on the token instead.
Where FastAPI Fits Into the Process
One common misconception is that FastAPI provides an entire authentication system.
It doesn’t.
FastAPI provides the framework for building APIs.
Authentication is something you build using FastAPI together with other libraries.
For example:
- FastAPI handles routing and dependency injection.
- Passlib hashes passwords.
python-josecreates and verifies JWTs.- SQLAlchemy retrieves users from the database.
- PostgreSQL stores user information.
Each component has a specific responsibility.
Together, they form the complete authentication system.
This modular design is one of FastAPI’s greatest strengths. Rather than forcing a single authentication solution on every project, FastAPI lets developers choose the tools that best fit their application’s requirements.
Looking Ahead
Authentication isn’t a single endpoint or a single library. It’s a collection of smaller pieces working together to establish trust between a client and an application.
Understanding that process first makes every implementation decision easier to follow.
In the next article, we’ll begin building that system by looking at one of its most important security principles:
Why passwords should never be stored in plain text, and how password hashing protects user credentials even if a database is compromised.
