What is a permission scope?

A scope is a string that names a single grantable permission, typically combining a resource (users, orders) and an action (read, write, delete). Tokens and roles are granted a set of scopes that define exactly what they can do.

What is the difference between the format options?

action:resource (read:users) is the classic OAuth style. resource:action (users:read) groups scopes by resource when sorted. The three-part resource:action:scope (orders:read:own) adds an ownership qualifier such as own or team.

Should I use read/write or finer-grained verbs?

Start coarse with read and write, and add finer verbs like create, update, delete, or list only where you genuinely need separate grants. Over-fine scopes create a permission sprawl that is hard to reason about.

What does the :own or :team qualifier mean?

It limits the action to records the caller owns or that belong to their team, versus all records. orders:read:own lets a user read only their orders, while orders:read:all would read every order. This encodes row-level access directly in the scope.

Is anything sent to a server?

No. The resource and action lists are bundled with the page and every scope is assembled in your browser. Nothing about your choices is uploaded or stored.

Permission Scope Name Generator

Authorization gets messy when scope strings are invented ad hoc. This tool generates permission scopes in consistent OAuth and RBAC formats, pairing a resource with an action and an optional ownership qualifier, so your access-control policy stays predictable and easy to audit.

How it works

A scope joins a resource (users, orders, invoices, reports) with an action (read, write, create, update, delete, list, manage) using a colon. You choose the word order: action:resource (the classic OAuth read:users) or resource:action (users:read, which groups by resource when sorted). A third format adds an ownership qualifier, producing resource:action:scope such as orders:read:own, where the qualifier (own, team, all) encodes row-level access. Each batch is de-duplicated.

Tips and example

Sample output in resource:action:scope format:

orders:read:own
invoices:write:team
users:manage:all
reports:list:team

Begin with coarse read and write scopes and split into finer verbs only where a real grant boundary exists. Fewer scopes are easier to reason about and audit.
Use the ownership qualifier to push row-level rules into the scope itself. orders:read:own is clearer than scattering ownership checks through application code.
Keep one canonical scope per permission. If both read:users and users:read exist for the same grant, your policy is ambiguous and bugs will follow.