Summary
Authorization review asks whether a principal may perform a defined action on a defined resource in a defined tenant or context. Authentication establishes an identity; it does not establish the effective permission.
Learning objectives and prerequisites
Use basic identity, role, permission, scope, token, claim, tenant, and API terminology. Identify intended authorization, tested enforcement, partial coverage, broader-than-intended permission, a bypass, delegated access unresolved, and insufficient evidence.
Why this matters
Hiding a user-interface control is not server-side enforcement. Role names may not reflect inherited, delegated, or effective permissions. Network isolation does not replace object-level authorization. One denied test does not prove every unauthorized path is blocked, and missing logs do not prove access was denied.
Core concepts and distinctions
Separate identity, principal, role, permission, scope, resource, tenant, object ownership, horizontal access, vertical access, cross-tenant access, delegated consent, service account, policy enforcement point, default deny, explicit allow, configured policy, effective policy, and evidence of enforcement. Client-supplied tenant identifiers require server-side validation; service-to-service trust can bypass a user-facing gateway.
Guided workflow
- Define the protected resource and intended access rule.
- Identify subjects, roles, tenants, claims, ownership, delegated access, and enforcement points.
- Review scopes, inherited permissions, service access, backend routes, and direct-object references.
- Define authorized and unauthorized tests for horizontal, vertical, cross-tenant, and service paths.
- Review logs, record unexpected access and limitations, assign ownership, and reassess after policy or deployment changes.
Fictional worked example
A fictional multi-tenant reporting application has users, tenant administrators, platform administrators, a service account, API gateway, backend API, object store, delegated reporting application, client-supplied tenant ID, and incomplete denial logging. A valid tenant administrator request confirms one intended path. Tests still need to show that a user cannot select another tenant, elevate a role, retrieve a direct object, or use the reporting integration beyond its delegated scope.
Decision exercise
For each fictional request, state the subject, resource, intended rule, enforcement point, expected result, evidence, and limitation. Include a negative test and a follow-up when the log is incomplete.
Knowledge checks and answer explanations
- Does authentication prove authorization? No; authentication identifies a principal, while authorization evaluates permitted action and resource context.
- Is client-side restriction sufficient? No; backend enforcement is required.
- Does a role name prove effective permission? No; inherited, delegated, and policy exceptions can change the result.
- Does one denied test prove tenant isolation? No; test the relevant paths and record coverage limits.
Common misconceptions
Network location replaces authorization, administrators are enough for testing, missing logs prove denial, or an access token proves access to every resource.
Practical takeaway
Write the rule as subject, action, resource, tenant, condition, enforcement point, expected result, evidence, limitation, owner, and reassessment trigger.
Related content
API Authorization Review, Identity Compromise Response, Investigation Evidence Quality, JWT Decoder, IAM Access Review Scenario, and Advisories.
Limitations
This lesson cannot validate a production permission, prove every trust boundary, or authorize testing outside approved scope.
Last reviewed: Unknown. Recheck local evidence before acting.