Authentication vs authorization

What it means

An account is not simply allowed or blocked for everything. Permission to read an item does not automatically include permission to edit it. A resource is the particular document or other object involved, so permission for one resource need not extend to another.

Here, viewer and editor describe two small sets of permissions declared by the example. The simulation compares identity status, role, and action; it does not model resource-specific access or establish that a real user holds the selected role.

Try it

Simulation: change Assigned role from viewer to editor, then select Compare with baseline to compare the starting and current outcomes. These controls change only the local teaching example, not a real account or permission.

The baseline result is Denied by toy policy. The account is authenticated but lacks edit permission. The identity prerequisite passes; the missing condition is the viewer role’s permission to edit.

Keep Identity established? = yes and Requested action = edit. Only Assigned role changes.

Reset restores Identity established? = yes, Assigned role = viewer, and Requested action = edit. It removes input errors and clears the baseline comparison. Reset preserves your independent open or closed choices for each FAQ answer and the About this model disclosure.

How it works

The declared policy requires an established identity and a grant for the selected action. Its supported branches are:

• If Identity established? is no, the request is denied regardless of role or action. The explanation is Identity is not established.
• If identity is established and Requested action is read, either viewer or editor is authorized.
• If identity is established and Requested action is edit, editor is authorized and viewer is denied.

In the baseline, the identity prerequisite is satisfied. The remaining condition is whether the selected role includes edit permission. Because viewer does not include it, the request is denied. Changing the role to editor changes that permission condition while leaving the identity evidence and requested action unchanged.

A real authorization decision must address the relevant resource as well as the action. Ownership and request context can also matter. The lab deliberately omits those dimensions so you can isolate one relationship; its role names must not be copied into a production policy as if they were universal grants.

Worked example

This is a synthetic baseline, not a captured request or production observation.

The identity requirement passes, but the edit-permission check does not: the declared viewer role permits reading, not editing. The result is Denied by toy policy. The account is authenticated but lacks edit permission. This is a permission failure within the example, not evidence that the account failed to sign in.

What changes when the condition changes

Change only Assigned role to editor. Identity established? remains yes, and Requested action remains edit. The result becomes Authorized by toy policy. This action is included in the selected role policy. Authentication has not improved or changed; the previously missing edit permission is now present.

There is a separate boundary: set Identity established? to no and Requested action to read, leaving Assigned role as editor. The result is Denied by toy policy. Identity is not established. Even the editor role cannot bypass this model’s identity prerequisite. That prerequisite is part of the declared example, not a claim that every real application must prohibit anonymous reading.

In practice

For an application you own or are authorized to inspect, begin with a read-only review of trusted server-side evidence. Keep the scope to the denied request: the established identity, requested action, particular resource, and applicable permission rule. Use approved test accounts and objects when reviewing allowed and denied cases; do not probe other users’ data.

The expected evidence is a connection between the request and the rule that allowed or denied it. An established identity together with a rule that does not grant the requested operation is consistent with an authorization denial. A role label displayed in the browser is not sufficient evidence of the server’s decision.

STOP if the identity, resource, or applicable rule cannot be established from trusted evidence. The cause remains unknown; do not broaden a role or weaken a check to make the denial disappear. Permission enforcement belongs at the server or trusted boundary for the relevant request, not solely in a hidden button or a browser-supplied role.

Verify your interpretation against documented expected outcomes for the same action and resource. A successful read does not verify edit permission or access to another object. This is a read-only investigation, not a procedure for changing roles or policy.

Limits and unknowns

This simulation evaluates only three local teaching inputs. It does not inspect a session, account, request, server, or deployed policy, and it performs no external action. There is no resource or ownership input, so an authorized result cannot establish access to a particular real document or another user’s object.

Every supported input combination receives a toy allow-or-deny result. The model has no setting for uncertain identity or unavailable policy evidence; those remain unknown in a real investigation until the missing evidence is collected. Identity established? = no is an explicit teaching input, not a substitute for uncertainty.

If an input is invalid, the calculated outcome is withheld rather than retaining an earlier result. Correct the input or use Reset. Without JavaScript, the initial example and explanation remain readable, but the interactive controls are unavailable.

What to carry forward

Treat identity evidence and permission evidence separately. A successful login is not enough to justify access, and permission for one action does not establish permission for another. For a denied operation, the useful next observation is the trusted permission decision for that exact action and resource—not a broader role assignment.