A practical guide to separating identity proof from permission decisions in access-control designs and exam scenarios.
Authentication and authorization are paired in almost every access-control system, but they answer different questions. Authentication proves the principal. Authorization decides whether that principal may perform a specific action on a specific resource.
That distinction is simple in vocabulary and surprisingly easy to miss in architecture and exam questions. A user who signs in successfully can still be denied by policy. A service with a valid token can still lack permission to read one object. A stronger MFA method can reduce account-takeover risk without granting any new rights.
| Step | Question | Example failure |
|---|---|---|
| Identification | Who claims to be making the request? | The username, service account, or workload identity is unknown. |
| Authentication | Can the claim be proven? | Password, MFA, certificate, assertion, or token validation fails. |
| Session or credential issuance | What proof will the system accept for later requests? | The identity provider signs in the user, but no valid application session is issued. |
| Authorization | Is this action allowed under policy? | The user can sign in but cannot delete a storage object. |
| Accounting and audit | Can the decision and action be traced? | The system allows access but cannot prove who did it. |
The shorthand AAA often means authentication, authorization, and accounting. In real systems, identification and credential issuance are also worth naming because many failures sit between “the user exists” and “the request is authorized.”
flowchart TD
A["Request arrives"] --> B{"Principal known?"}
B -- "No" --> X["Reject or start sign-in"]
B -- "Yes" --> C{"Credential valid?"}
C -- "No" --> Y["Authentication failure"]
C -- "Yes" --> D{"Action authorized?"}
D -- "No" --> Z["Authorization failure"]
D -- "Yes" --> E["Perform action and log context"]
Use the flow in troubleshooting. If there is no valid credential, changing a permission policy cannot fix the first failure. If there is a valid credential but the action is denied, adding another MFA method is not the direct fix.
| Proof | Useful when | Main risk |
|---|---|---|
| Password | Low-risk human access with compensating controls | Phishing, reuse, guessing, leakage |
| MFA factor | Higher assurance for human sign-in | Weak factors can be phished or socially engineered |
| Certificate | Device, workload, mutual TLS, or managed endpoint identity | Lifecycle and private-key protection |
| Signed assertion | Federation between identity provider and service provider | Trust configuration, audience, expiry, claims |
| Bearer token | API and application access after sign-in | Theft grants use until expiry or revocation |
| Hardware-backed key | Phishing-resistant human authentication | Enrollment, recovery, device management |
Authentication strength is about the quality of proof. It is not the same thing as permission scope.
| Model | How access is decided | Typical use |
|---|---|---|
| Access control list | Resource lists allowed principals | Simple resource-local permissions |
| Role-based access control | Principal receives permissions through a role | Job functions, cloud roles, Kubernetes roles |
| Attribute-based access control | Decision uses attributes about principal, resource, action, and context | Conditional, large-scale, dynamic policies |
| Policy-based access control | A policy engine evaluates rules and conditions | Cloud IAM, service meshes, SaaS authorization |
| Capability or token scope | The credential carries a limited capability or scope | OAuth scopes, presigned URLs, delegated APIs |
Many systems combine these. Cloud access may involve identity policy, resource policy, organization-level guardrail, session policy, encryption key policy, and network condition before a request succeeds.
| Prompt clue | Likely layer |
|---|---|
| “User cannot sign in” | Authentication, identity source, MFA, federation, or account status |
| “User signs in but receives access denied” | Authorization policy, resource policy, scope, or guardrail |
| “Application stores access keys in code” | Credential management and workload identity |
| “Admin needs temporary elevated permissions” | Privileged access and authorization lifetime |
| “Auditor cannot determine who performed the action” | Accounting, logging, shared accounts, session attribution |
When an answer choice solves the wrong layer, it is usually a distractor even if the technology named in the answer is real.
Strong access designs use separate controls for separate risks:
A cloud administrator can sign in through the company’s identity provider and open the cloud console, but attempts to update a production database fail with an access-denied message. Which area should be checked first?
A. Whether the administrator’s password meets length requirements
B. Whether the role, resource policy, or guardrail authorizes the database update action
C. Whether the identity provider’s login page is reachable from the internet
D. Whether the administrator can receive an MFA push notification
Best answer: B. The user has already authenticated and obtained a session. The failure is now in authorization evaluation: role permissions, resource policy, guardrails, conditions, or a related boundary.