A successful sign-in proves an identity. It does not automatically grant permission to every resource or action. This lesson turns that distinction into a practical troubleshooting method.

What you will be able to do

Distinguish authentication evidence from authorization decisions in a real access request.
Apply strong authentication and least-privilege authorization guardrails.
Troubleshoot a denied or unexpected access result with safe, observable evidence.

Two decisions behind every protected action

Authentication and authorization answer different questions. Authentication establishes which person, device, or service is acting. Authorization evaluates whether that subject may perform a particular action on a particular resource. A valid sign-in is therefore not a universal access pass. In a file service, the identity provider may confirm Jordan's account while the file service separately denies Jordan permission to delete a finance report. Keep the decisions separate in diagrams, logs, tests, and incident notes. When a request fails, first state the exact subject, resource, and action instead of saying only that access is broken.

Read authentication evidence without exposing secrets

Useful authentication evidence includes the account identifier, identity-provider result, authenticator type, session creation time, reauthentication event, and protected audit records. It does not include passwords, recovery codes, private keys, or raw session tokens. A centralized identity provider can simplify sign-in and account lifecycle work, but the relying application still has to enforce its own access policy correctly. A safe investigation records timestamps and correlation identifiers, checks whether the expected identity reached the application, and confirms whether the session is current. Redact secrets before sharing evidence and use the minimum access needed to inspect protected logs.

Reconstruct the authorization decision

An authorization decision can use roles, explicit access lists, subject attributes, resource attributes, relationships, requested actions, and environmental context. The correct model depends on the system, so do not assume that one role name explains every result. Reconstruct the decision with a compact tuple: subject, resource, action, policy version, and decision. Then inspect the inputs that the enforcement point actually received. A user interface that hides a button is not evidence that the server blocks the operation. Direct API calls and object-specific requests must reach the same policy enforcement path.

Choose authentication controls by risk

Multifactor authentication combines independent factor types. Two passwords are still two examples of the same factor category and do not provide the assurance of independent factors. MFA is also not automatically phishing-resistant: the resistance of the specific method must be evaluated separately. Privileged and high-impact access should favor phishing-resistant methods where feasible. Sessions also need bounded lifetimes, reauthentication rules, and reliable invalidation. A successful sign-in from yesterday must not be treated as permanently sufficient for every sensitive action today.

Build authorization guardrails

Start from deny by default: an unmatched request remains denied until an explicit policy grants the subject the requested action on the resource. Enforce authorization on every protected request, not only on menus or page routes. Apply least privilege so accounts receive only the permissions required for approved work, and review access periodically to detect privileges accumulated through job changes or temporary assignments. Test both expected allows and expected denies. An allow-only test suite can miss object-level exposure, alternate endpoints, and stale privileges.

Use the symptom-to-cause decision tree

Begin with the observed request. If no current authenticated identity reached the application, investigate the identity, authenticator, session, and federation path. If the expected identity is present, move to authorization and record the exact subject, resource, and action. If the policy input is wrong, trace role, attribute, group, relationship, or lifecycle data. If the input is correct but the decision is wrong, inspect policy version and evaluation. If the decision is correct but enforcement differs, inspect the protected endpoint and object lookup. Change one variable at a time, preserve timestamps and correlation identifiers, and stop before collecting secrets or weakening a production control.

Safe verification lab

Use a disposable lab with two test identities, two records, and three operations: read, update, and delete. Give the operator read and update access to record A, read-only access to record B, and no delete permission. Capture a correlation identifier for each request. Verify one expected allow and one expected deny for every operation, including a direct object request that bypasses normal navigation. Confirm that denied attempts create protected review evidence without returning sensitive policy details to the user. Repeat after removing a role and after invalidating the session. The observable result should change promptly and match the recorded policy state.

Review, recover, and prevent recurrence

After resolving the immediate symptom, check whether the same cause affects other accounts or resources. Review account lifecycle events such as transfers, privilege removal, disablement, and termination, because stale identity data can keep obsolete access alive. Remove temporary diagnostic permissions and invalidate sessions when required. Record the confirmed cause, safe evidence, policy or lifecycle correction, and negative tests that now pass. The final review should show that the intended user can complete approved work, an unapproved user is denied, object-level checks hold, and protected logs contain enough evidence for future investigation.

Authentication vs. Authorization