Role-based access control in Microservices - System Design Guide

Problem Statement

When users have unrestricted access to all parts of a microservices system, sensitive data can be exposed and unauthorized actions can occur. Without clear boundaries, it becomes impossible to enforce security policies consistently across multiple services, leading to potential breaches and compliance failures.

Solution

Role-based access control assigns users to roles that define their permissions. Each microservice checks the user's role before allowing access to resources or actions. This centralizes permission management and ensures consistent enforcement of security rules across the system.

Architecture

User Client ├──────▶

→API Gateway ├──────▶

↓

Role & Token

Validation

↓

Microservice 2

(Checks Role)

This diagram shows a user request passing through an API Gateway to an Auth Service that issues role-based tokens. Microservices validate these tokens and enforce access based on user roles.

Trade-offs

✓ Pros

→

Centralizes permission management, simplifying updates and audits.

→

Enables consistent security enforcement across multiple microservices.

→

Reduces risk of unauthorized access by limiting user actions to assigned roles.

→

Scales well as new services and roles are added without redesigning access logic.

✗ Cons

→

Requires careful role design to avoid overly broad or too restrictive permissions.

→

Adds complexity to service interactions due to token validation and role checks.

→

Changes in roles may require token refresh or session invalidation to take effect.

Use when your system has multiple microservices requiring consistent access control and when user actions must be limited by roles, especially at scale beyond hundreds of users.

Avoid if your system is a simple single-service app with few users, where role management overhead outweighs security benefits.

Real World Examples

Uber

Uber uses RBAC to ensure drivers, riders, and support staff have access only to the data and actions relevant to their roles, preventing data leaks and unauthorized operations.

Amazon

Amazon Web Services implements RBAC to control user permissions across its vast cloud services, enabling fine-grained access control for customers and internal teams.

LinkedIn

LinkedIn applies RBAC to restrict access to user data and administrative functions, ensuring compliance with privacy regulations and internal policies.

Code Example

The before code allows any user to create orders without checks. The after code verifies the user's roles include 'order_creator' before proceeding, enforcing RBAC.

Microservices

### Before: No role checks in microservice endpoint
class OrderService:
    def create_order(self, user, order_data):
        # No access control
        process_order(order_data)
        return "Order created"


### After: Role-based access control applied
class OrderService:
    def create_order(self, user, order_data):
        if 'order_creator' not in user.roles:
            raise PermissionError("User lacks permission to create orders")
        process_order(order_data)
        return "Order created"

Alternatives

Attribute-based access control (ABAC)

ABAC uses user attributes and resource properties for access decisions instead of fixed roles.

Use when: Choose ABAC when access rules require fine-grained, dynamic policies based on multiple user and resource attributes.

Access control lists (ACL)

ACLs specify permissions per user or group directly on each resource rather than via roles.

Use when: Choose ACLs for simple systems with few users and resources where direct permission assignment is manageable.

Summary

Role-based access control limits user actions by assigning permissions to roles rather than individuals.

It centralizes security management and enforces consistent access rules across microservices.

RBAC is best for systems with multiple services and users requiring clear permission boundaries.