Name the capability
A scope should communicate what access a client is requesting. Prefer understandable capabilities over names that expose incidental implementation details. Decide which API owns the meaning of each scope.
Avoid a single unrestricted scope simply because the first client needs broad access. It can make later separation difficult.
Keep scopes and business rules separate
Permission to call an order API does not imply permission to read every customer’s order. The API still needs to check ownership, roles or other business rules for the specific resource.
Also distinguish the token audience from its scopes. One describes the intended recipient; the other describes the delegated access.
Review the complete contract
For each client, list required operations and the least access that supports them. Keep identity-server registration and API authorization policy aligned.
Test missing scopes, wrong audiences and access to someone else’s resource. A documented scope is useful only when the receiving API enforces its intended boundary.
Further reading
Primary documentation & specification