Authorization, in practice

What it means

Authorization evaluates a requested action against a policy. The decision usually depends on who or what is asking, the target resource, and the operation. Context may also matter, such as an approved time window or the relationship between a user and a record. Public access is an authorization choice too; some resources intentionally permit anonymous readers.

Authentication supplies identity evidence but does not replace these checks. Enforce authorization where the resource is served, not only in the browser interface. A user who cannot see an export button might still send an export request directly. Policies need both allowed cases and explicit boundaries that tests can exercise.

See the idea / Identity

Signed in. Which referral may you open?

Try two records with the same signed-in account. The server checks permission for each request.

You work at Clinic A. This example policy lets staff view referrals belonging to their own clinic.

01 / 04

Choose

You are signed in as Clinic A staff. Choose a referral to request.

More about this step

Authentication established your account's identity. This example starts with an active session. The application must still decide whether you may view the particular referral.

Keep in mindA fictional clinic policy with synthetic records. Real policies vary; public resources may permit anonymous access. Hiding a button is not an access check.

Read the visual, step by step

Choose. You are signed in as Clinic A staff. Choose a referral to request. Authentication established your account's identity. This example starts with an active session. The application must still decide whether you may view the particular referral.
Request. Your browser asks to view referral A-104. No referral content has arrived yet. The request carries the referral identifier and your session. The application resolves the requester from that session and finds the record's clinic from trusted server-side data. A client-supplied clinic label is not proof of permission.
Check. The server checks the viewing permission and clinic match. Both pass for this Clinic A referral. This example policy requires permission to view referrals and a match between the staff member's clinic and the referral's clinic. Both conditions are evaluated at the server for this request. Access is denied unless the required conditions pass.
Reply. Permission passed. The application returns A-104; your browser displays the referral after the response arrives. The server returns the permitted referral over HTTPS. Opening this record grants no blanket access to other referrals. Every later request needs its own applicable permission checks; your sign-in remains the same.

Another clinic's referral

Choose. You are still signed in as Clinic A staff. Try a referral belonging to Clinic B.
Request. The same browser asks to view B-208. Changing the record identifier does not grant permission. A request can reach the server even if the interface hides a link or button. The server checks the authenticated account and trusted record attributes; guessing an identifier does not establish entitlement.
Check. The viewing permission passes, but the clinics do not match. The server denies this request. The staff member can view referrals, but this referral belongs to another clinic. The action permission alone is insufficient. The clinic condition fails, so this example policy denies access while the session remains valid.
Reply. The application returns an access-denied response with no referral content. You remain signed in. The browser receives a refusal, not the protected record. This diagram uses a generic access-denied message; real applications may conceal whether a record exists. A denied operation does not itself mean authentication failed or the session ended.

A fictional clinic policy with synthetic records. Real policies vary; public resources may permit anonymous access. Hiding a button is not an access check.

Flow references: OWASP: authorization checks

AN ILLUSTRATIVE SCENARIO

A healthcare referral service

A referral service allows clinic staff to view referrals assigned to their clinic. Two staff accounts can both sign in, but that does not entitle either to every referral. The application checks the clinic associated with the requested record as well as the user's permitted action. During testing, a developer uses synthetic referrals for two clinics and confirms that changing a record identifier does not reveal the other clinic's data.

Put it to work

Describe access in terms of requester, action, and resource; include ownership or organizational boundaries rather than relying only on broad job titles.
Enforce checks consistently on the server for each relevant request, including downloads, background operations, and alternate application interfaces.
Create positive and negative tests with different users, resources, and roles; review the policy when responsibilities or data relationships change.

How to check your work

Use two test identities to demonstrate that each can perform its legitimate work and that cross-record or excessive actions are denied. Preserve the policy and representative test results together.

Connect the ideas

Authentication
The act of verifying a claimed identity with authenticators such as passwords, passkeys, or certificates.
Least privilege
Granting each identity only the actions, objects, and time window required for the current job.
Trust boundary
A place where identity, network, or data assumptions change and a fresh check is required.
Session
State linking multiple requests; an authenticated session associates later requests with a previously authenticated identity until it expires or is revoked.

Authorization