Implementing RBAC with Dependency-Based Permissions

What is Role-Based Access Control (RBAC)?

At its core, RBAC is a security model that controls access to resources based on the roles of individual users within an organization. Instead of assigning permissions to users one-by-one, you assign permissions to roles, and then assign roles to users. This simplifies administration, especially as the number of users and resources grows.

1. Adding Roles to the User Model

To check for a user's role, we first need a place to store it. The most direct way to do this is by adding a role field to our User model in the database.

In Django, this would be as simple as adding role = models.CharField(max_length=50, default='user') to your User model. The process with SQLAlchemy is very similar. We'll add a new column to our User table to store the role as a string, with a default value of "user" for all new and existing users.

This video will walk you through the practical steps of modifying the SQLAlchemy model and applying the change to your database using an Alembic migration.

After updating the model, we also need to ensure that new users are assigned a role upon creation and that this role is included in the access token. This makes the role readily available for our authorization logic.

2. The Role-Checking Dependency

Now for the main event: creating a dependency that checks for roles. We could create a specific is_admin dependency, but that's not very reusable. What if we need to check for a "manager" or "editor" role later?

A better approach is to create a single, parameterized dependency. We can tell it which roles are allowed for a specific endpoint. A class is the perfect tool for this.

The Django Analogy: Think of this as creating a flexible permission class in DRF where you can pass arguments, like permission_classes = [HasRole('admin', 'moderator')].

In FastAPI, we'll create a RoleChecker class:

• The __init__ method will accept a list of allowed roles.
• The __call__ method, which makes the class instances callable, will contain the actual checking logic. This method will itself use Depends(get_current_user) to get the current user.

Let's watch how this is built.

Here is the key logic from the video in a simplified form:

from fastapi import Depends, HTTPException, status



# Assume get_current_user and User schema are imported

class RoleChecker:
    def __init__(self, allowed_roles: list[str]):
        self.allowed_roles = allowed_roles

    async def __call__(self, current_user: User = Depends(get_current_user)):
        if current_user.role not in self.allowed_roles:
            raise HTTPException(
                status_code=status.HTTP_403_FORBIDDEN,
                detail="You do not have permission to perform this action",
            )

This pattern is clean, reusable, and type-safe.

3. Protecting Routes with the RoleChecker

With our RoleChecker class defined, we can now create instances of it for different permission levels and apply them to our routes.

For example, to create a check that only allows admins:
admin_only_check = RoleChecker(allowed_roles=["admin"])

To apply this, FastAPI gives us a very clean way to add dependencies that run but whose return value we don't need in the function body: the dependencies list in the path operation decorator.

This next segment shows exactly how to use our new checker.

Here's an example of how you might protect a route for deleting users, making it accessible only to admins:

# In a file where you define reusable dependencies
admin_access = RoleChecker(allowed_roles=["admin"])
user_and_admin_access = RoleChecker(allowed_roles=["user", "admin"])




# In your user_router.py file
@router.delete(
    "/{user_id}",
    status_code=status.HTTP_204_NO_CONTENT,
    dependencies=[Depends(admin_access)] # <-- Protection!
)
async def delete_user(user_id: int, db: DbSession):



    # This code will only execute if the current user has the 'admin' role.
    # ... logic to delete the user ...
    return Response(status_code=status.HTTP_204_NO_CONTENT)

This nested dependency pattern (RoleChecker depending on get_current_user) is extremely common and powerful for building layered authorization.

4. Thinking Ahead: Advanced RBAC and ABAC

The simple string-based role we've implemented is great for many applications, but as systems grow, you might need more. What if a user has multiple roles? What if permissions are more granular than just a role name (e.g., "can edit posts in the 'news' category")?

This leads to more advanced models like:

• Granular RBAC: Using many-to-many tables for users_roles and roles_permissions.
• Attribute-Based Access Control (ABAC): Where permissions depend on attributes of the user (role, department), the resource (sensitivity level), and the environment (time of day).

You don't need to implement this now, but as someone interested in modern architecture, it's valuable to see what a production-grade system looks like.

This article gives you a mental roadmap for how to evolve the simple RBAC system we built today into a comprehensive, attribute-based authorization engine if your project requires it.

Conclusion

Congratulations! You've successfully extended FastAPI's dependency injection system to handle role-based authorization. You now have a clear, reusable, and testable pattern for controlling access to your API endpoints based on user roles.

Key Takeaways:

• RBAC starts at the data layer: You need to store user roles in your database, typically on the User model.
• Class-based dependencies are ideal for parameterized checks: The __init__ method configures the dependency (e.g., with allowed roles), and the __call__ method executes the check.
• Dependencies can depend on other dependencies: Our RoleChecker relies on get_current_user to get the authenticated user, creating a clean chain of responsibility.
• Use the dependencies decorator argument for pure authorization: This keeps your endpoint signatures clean by separating permission checks from the parameters your business logic needs.
• FastAPI's patterns scale: The dependency system can be extended from simple role checks to complex ABAC systems by elaborating on the logic within the dependency.

Preview of the Next Lesson:

Our application is growing in complexity. We now have logic for authentication, users, posts, and permissions spread across different files. In the next lesson, we will focus on Modern API Architecture and Project Structure. We will learn how to organize a FastAPI project into a scalable folder structure, manage settings, and begin introducing patterns like the repository and service layers to prepare our application for long-term maintenance and growth.