Authorization

Authorization decides whether a caller may perform a particular action on a particular resource under the current conditions. Authentication establishes who is calling; authorization determines what that identity is allowed to do. Some resources intentionally permit anonymous access, so a named login is not required for every authorization policy.

Check the resource, not just the screen

A manager may read their own store's sales but not another store's payroll. Hiding a payroll button does not enforce that rule if the service still accepts a direct request. The server must check the requested action and resource.

Policies may use roles, attributes, ownership, or relationships. OWASP recommends least privilege, denying access by default unless permitted, and validating permissions on requests. A role name alone does not capture every condition, such as which store owns a record.

Copies must respect current permissions

Suppose a policy document becomes restricted after an assistant caches an answer from it. Reusing that answer can expose information even if fresh retrieval is blocked. Apply the required permission rules to cached and derived results as well as source reads.

Record policy versions and decisions as appropriate for investigation. Test both allowed and denied cases, including cross-user and cross-tenant requests. A successful authentication or an obscure resource identifier is not a substitute for authorization.

Reference: OWASP: Authorization.