Permission and policy denials after identity has been authenticated.
Last reviewed: February 13, 2026|7 mapped errors
Authorization errors indicate that caller identity is known, but effective policy evaluation denies the requested action at the current scope.
Provider-specific error pages mapped to this category (7 total). Showing 1-7.
AWS AccessDenied means authorization failed for the requested action and resource. In S3 this is typically HTTP 403, while some AWS Query APIs return an AccessDenied variant with HTTP 400.
AWS OptInRequired (Opt In Required) means the account or access key is not subscribed/opted in to the target AWS service. AWS common errors define it as "the AWS access key ID needs a subscription for the service" (HTTP 403).
AWS SignatureDoesNotMatch (Signature Does Not Match) means AWS recalculated the SigV4 signature and it does not match the signature in the request. In Amazon S3, this error returns HTTP 403.
Azure returns `Forbidden` (403) when the caller is authenticated but blocked by authorization, policy, or service-level access controls.
GCP PERMISSION_DENIED means the caller identity is recognized, but IAM or policy controls block the requested action on the target resource.
HTTP 403 Forbidden means the server understood the request but refuses to authorize this action.
HTTP 425 Too Early means the server is unwilling to process a request that could be replayed.
Compare Guide
Fix 401 Unauthorized vs 403 Forbidden by separating authentication failures from authorization denials, then apply the right login or permission fix fast.
Compare Guide
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Compare Guide
Compare AWS AccessDenied and GCP PERMISSION_DENIED to isolate authorization deny layers, separate auth failures, and apply precise IAM fixes fast.
Playbook
Use this playbook to triage policy-based access denials after authentication succeeds, isolate the deny layer, and apply least-privilege remediation safely.
Yes. Authentication proves identity, but authorization evaluates what that identity can do. Valid identity can still be denied by policy scope or explicit deny.
Rotating credentials before checking policy decisions. Most 403-like incidents are policy or scope problems, not token cryptography failures.
Audit policy evaluation by scope order (organization/account/project/resource) and log the first explicit deny source for each failed request.