Phase 3: Authentication & Security

Granular permission systems beyond admin/user roles

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you and your friends are putting on a big school play! At first, it might seem simple: there's the 'Director' who runs everything, and then there are the 'Actors' who perform. But pretty soon, you'd realize it's not that simple, right? What about the person who designs the costumes? Or the one who sets up the lights? Or the friend who just helps hand out programs at the door? They're not exactly 'Directors' and they're not just 'Actors' either. Giving everyone who isn't the Director the same 'Actor' label doesn't really make sense because they all do totally different things.

This is exactly what happens with computers when we build apps and websites. Instead of just saying someone is an 'Admin' (like your play's Director) or a 'User' (like an Actor), we can give people super specific jobs, like giving them special 'permission slips' for exactly what they're allowed to do. So, for our play: the costume_designer gets a permission slip that says they can create_costumes and alter_costumes. The lighting_tech gets a slip saying they can adjust_lights and change_light_colors. The stage_manager can move_props and call_actors_to_stage. And a regular actor gets a slip that says perform_lines and stand_on_mark. No actor would have permission to move props or change lights, just like the lighting tech wouldn't perform lines.

These tiny, specific permission slips are what we call 'granular' permissions. 'Granular' just means super detailed, like grains of sand – you can pick out individual pieces. This way, when you make a game or an app, you can be really precise about who can do what. Think about a game where some players can build new levels, some can just play levels, and some can help moderate the chat. You wouldn't want everyone to be able to delete someone else's amazing level, would you? Only the level creator or a super trusted moderator should have that special delete_level permission.

So, when you start thinking about building your own cool websites or apps, using these specific permission slips means you can create really fair and safe systems. You can let different friends have different powers without worrying about someone accidentally (or on purpose!) messing up something they shouldn't. It means you can build complex worlds where everyone has an important, distinct role, making your creations much more organized and secure!

While basic admin/user roles offer a straightforward start, real-world applications quickly outgrow such simple distinctions. Granular permission systems move beyond this by providing fine-grained control over specific actions a user can perform, rather than just classifying them broadly. Imagine a project management tool: not all "users" are equal. A team member might view_tasks and update_their_own_task, while a project lead needs to assign_tasks_to_any_user or archive_project. This level of detail is impossible with just is_admin or is_user, as different user types need highly specific sets of permissions tied to their responsibilities.

Key Takeaways

  • Simple admin/user roles are insufficient for complex applications.
  • Granular systems define specific, atomic permissions for individual actions (e.g., project:edit, user:delete).
  • RBAC (Role-Based Access Control) helps organize these permissions by grouping them into roles (e.g., a 'Project Manager' role has many granular permissions).
  • Permissions are enforced at the API or application layer through policies or code checks.
  • This approach provides precise control, enhances security, and offers greater flexibility for evolving business logic.

Code Example

python
# A simplified example of checking granular permissions
# Assuming 'current_user' object has a method to check permissions

def check_permission(permission_name):
    # In a real app, current_user would come from context/session
    current_user = get_authenticated_user()

    if current_user and current_user.has_permission(permission_name):
        return True
    return False


def create_project(project_data):
    if not check_permission("project:create"):
        raise PermissionError("User not authorized to create projects.")
    # ... logic to create project ...
    print("Project created successfully.")


def delete_user_account(user_id):
    if not check_permission("user:delete_any"):
        raise PermissionError("User not authorized to delete other user accounts.")
    # ... logic to delete user ...
    print(f"User {user_id} deleted.")

# Helper for demonstration (not part of actual system)
def get_authenticated_user():
    # This would simulate a user with some permissions
    class MockUser:
        def has_permission(self, perm):
            return perm in ["project:create"]
    return MockUser()

# Example Usage:
# create_project({'name': 'New Project'})
# delete_user_account(123) # This would fail if user only has 'project:create'

How this code works

This code demonstrates how to implement a granular permission system, allowing applications to verify precise permissions before performing actions. The core check_permission function takes a specific permission name, like project:create. It first retrieves the current_user (simulated by get_authenticated_user for this example), then checks if this user possesses that exact permission using current_user.has_permission. If the user has the required permission, the function returns True, allowing the operation to continue.

Functions like create_project and delete_user_account rely on check_permission to enforce authorization. They call check_permission at the start, and if it returns False, they immediately raise a PermissionError, preventing unauthorized actions. A subtle but important aspect is within get_authenticated_user: the MockUser it creates is hardcoded to only have the project:create permission. This design choice means that while create_project would succeed, a call to delete_user_account (which requires user:delete_any) would fail, showcasing how specific permissions gate access to distinct functionalities.

Related Articles

Hand-picked reads to go deeper on authorization & rbac.

Back to Backend Developer Roadmap