Authorization

---

name: Authorization slug: authorization version: 1.0.0 homepage: https://clawic.com/skills/authorization description: Build secure access control with RBAC, ABAC, permissions, policies, and scope-based authorization. metadata: {"clawdbot":{"emoji":"🔐","requires":{"bins":[]},"os":["linux","darwin","win32"]}}

When to Use

User needs to control what actions users can perform. Agent handles permission design, role hierarchies, policy evaluation, and access control middleware.

Quick Reference

Core Rules

1. Auth ≠ Authorization

• Authentication: Who you are (login, OAuth, tokens)
• Authorization: What you can do (permissions, roles, policies)
• Never mix concerns — auth happens BEFORE authorization

2. Principle of Least Privilege

• Default deny — explicit grants only
• Users get minimum permissions for their job
• Audit permissions periodically (revoke unused)
• Temporary elevation over permanent grants

3. Choose the Right Model

Start simple → evolve when needed.

4. Role Design Patterns

• Roles represent jobs, not permissions
• Max 3 inheritance levels (admin → manager → user)
• Avoid role explosion — combine with ABAC for edge cases
• Document role definitions (what can this role DO?)

5. Permission Naming

resource:action:scope
documents:write:own     ← Can edit own documents
documents:write:team    ← Can edit team documents
documents:delete:all    ← Can delete any document

Consistent naming prevents ambiguity.

6. Policy Evaluation Order

1. Explicit deny → always wins
2. Explicit allow → checked second
3. No match → default deny
4. Log all denials for debugging

7. Never Hardcode

// ❌ Bad — hardcoded role check
if (user.role === 'admin') { ... }

// ✅ Good — permission check
if (can(user, 'settings:update')) { ... }

Roles change. Permissions are stable.

Common Traps

• Checking roles instead of permissions → brittle when roles change
• OR logic in permissions → "can edit OR is admin" creates backdoors
• Caching permissions too long → stale grants after role changes
• Frontend-only checks → always verify server-side
• God roles → split "admin" into specific permission sets
• Circular inheritance → A inherits B inherits A crashes system

Security & Privacy

Data that stays local:

• All documentation and patterns are reference material
• No data collection or external requests

This skill does NOT:

• Access your codebase automatically
• Make network requests
• Store any user data

Feedback

• If useful: clawhub star authorization
• Stay updated: clawhub sync