How would you model roles and permissions for an API without creating a messy role explosion?

Compare roles, permissions, and capabilities

Explains how roles group permissions while API policies enforce specific capabilities and resource rules.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would use roles as coarse user-facing groups and permissions or capabilities as the specific actions the API checks. For example, Editor can include content read and update, while Admin can include user management. The endpoint checks the capability it needs, not a broad role name everywhere. That avoids adding a new role for every tiny workflow difference.

Full answer below

Practice focus

Roles, permissions, capabilities, policy checks, role explosion, least privilege, and resource-level authorization.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Role modeling is a common source of long-term security and product pain. The useful answer keeps roles human-friendly while enforcing precise permissions in code.
I would use roles as coarse user-facing groups and permissions or capabilities as the specific actions the API checks. For example, Editor can include content read and update, while Admin can include user management. The endpoint checks the capability it needs, not a broad role name everywhere. That avoids adding a new role for every tiny workflow difference.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would keep the permission list small and tied to real product actions: content publish, user manage, import run, suggestion review, and so on. Roles become assignments of those capabilities. Some checks still need resource context, such as own record versus any record, tenant membership, or content status. A capability can say the user may attempt an action; the resource policy decides whether this specific target is allowed.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Checking only broad Admin roles for unrelated actions.
Creating many one-off roles instead of reusable capabilities.
Ignoring resource ownership after a capability check passes.
Letting frontend navigation decide access.

How would you model roles and permissions for an API without creating a messy role explosion?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement

Found this answer useful?