Role-based access control decision
Authorization logic: user roles, permissions, and resource access checks.
Every application needs to control who can see and do what. This diagram shows the authorization logic that protects resources: fetch the user and their roles, check if the role grants permission for the action, then verify the user owns or has access to the specific resource. The key is the two-level check — role-based permissions guard broad access (can editors edit at all?), while resource-level checks enforce ownership (can this editor edit this document?).
Teams without clear RBAC logic ship bugs: an editor accidentally sees another user's private document, or a viewer makes a POST request that goes through. This diagram makes the authorization logic explicit and testable, so you can verify every code path returns the right response.
When to use this template
- Authorization architecture — design your role hierarchy and permission matrix before building the code, so engineering and product agree on what each role can do.
- Security review — walk through the diagram with your security team to spot missing checks (rate limiting? logging? resource ownership?).
- Developer documentation — drop this into your internal wiki so new engineers understand the authorization flow before touching the auth code.
How to adapt it
Extend the diagram to match your security model:
- Add an organization check before resource access, so users in different organizations never see each other's data even if they have the same role.
- Insert a rate limit check after authentication, so you prevent brute-force attacks at the authorization layer.
- Replace the binary owner check with a shared access list, so users can grant colleagues specific permissions to their resources.
Visual edits regenerate clean Mermaid code, so you can turn this template into your team's actual authorization rules by adjusting the conditions and adding checks in the editor.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[User requests access to resource] --> B[Fetch user account]
B --> C[Load user roles from database]
C --> D{User has admin role?}
D -->|Yes| E[Grant full access]
E --> F[Log access grant]
F --> G[Return resource]
D -->|No| H[Check roles for resource]
H --> I[Load role permissions]
I --> J{Role has required permission?}
J -->|Yes| K[Check resource attributes]
K --> L{Owner or shared with user?}
L -->|Yes| F
L -->|No| M[Access denied]
J -->|No| M
M --> N[Log access denied]
N --> O[Return 403 Forbidden]
Frequently asked questions
- What is role-based access control (RBAC)?
- RBAC is a security model where permissions are assigned to roles (admin, editor, viewer), and users get roles instead of individual permissions. This diagram shows the logic: fetch the user and their roles, check if the role has permission for the action, then verify they own or have access to the specific resource. RBAC scales better than assigning permissions directly to users, especially in multi-tenant systems.
- What is the difference between authentication and authorization?
- Authentication answers 'are you who you say you are?' (login). Authorization answers 'are you allowed to do this?' (access control). This diagram is the authorization step. You'd run it after authenticating the user — once you know who they are, this logic decides what they can see and do.
- Why check both the role and the specific resource?
- Because not every editor should edit every document. A user might have the 'editor' role, which grants permission to edit documents in general, but still can't edit a document they don't own. This diagram shows both checks: first, does their role allow editing? Second, do they own or have access to this specific document? Both must pass.
- Should I cache role permissions or check the database every time?
- Cache permissions for speed, but set a TTL (time to live). If a user's role changes, the cache needs to expire within seconds so they either gain or lose access quickly. This is a trade-off: caching makes authorization fast, but adds a brief window where the cache is stale. Most systems cache for 5–60 seconds, then revalidate.