By Ronnie Mbuqe
Authentication establishes who is making a request. Authorisation decides whether that identity may access the particular record or action.
A server must check ownership or permission even when the screen hides the link. Anyone can alter a URL or construct a request outside the intended interface.
A valid login must not unlock another customer's reservation
You sign in, open your booking and change the booking number in the address. The server must check whether the requested record belongs within your permitted access. Recognising your session alone is not enough.
We will follow identity and permission as two separate decisions. The aim is to understand where a protected request must be checked, even if the page never displayed the forbidden link.
Does signing in prove you are allowed to access every record?
Authentication establishes an identity or credential claim.
Trace the explanation
Authorisation checks whether that identity may perform a particular action on a particular resource. Hiding a menu item is not a substitute for enforcing access on the server.
Source and further reading: cheatsheetseries.owasp.org
Knowing who you are does not mean you may open every booking
Authentication establishes an identity in a context; authorisation checks what that identity may do. If a signed-in user changes a booking number in a URL, the server must still confirm that the requested record is allowed for that user.
Hiding another customer's link is not enough. The browser is under the caller's control, so record-level permission checks belong at the protected operation. A valid session token should not become a master key to every row in the database.
Keep the record check at the protected operation
Alice is signed in and requests booking B42. If B42 belongs to Bob and Alice has no delegated permission, the service rejects access. Hiding B42 from Alice's menu would improve the interface but would not protect the endpoint against a direct request.
Now let Alice request her own booking A17. Identity is still checked, and the record-level permission can succeed. Authentication answers who the caller is in this context; authorisation answers whether this operation on this record is allowed.
The same rule applies when an edit is sent directly without opening the original page. Sessions can expire or be revoked between requests, so the protected server operation must enforce its current requirements.
Alice has a valid login but no permission for Bob's booking. Should access be allowed? Type yes or no.
This checks a prediction about the worked example. It does not run server code, contact an API or change a booking.
No. A valid identity does not supply permission for every record. The server must enforce the actual authorisation rule.Read the explanation without the checker
No. A valid identity does not supply permission for every record. The server must enforce the actual authorisation rule.
Apply the same reasoning to deleting a comment. Knowing who posted the request is not yet evidence that they own the comment.
Practical examples: Authentication
Banking
A bank may combine a password, registered device, one-time code and risk signals. Successful authentication starts a limited session, but every account request still checks permission. Extra verification may be required when the device, location or transaction looks unusual.
Email
An email provider must protect messages even if someone guesses an address. It rate-limits attempts, stores password hashes instead of readable passwords and offers recovery methods. Recovery itself is a high-risk authentication path and needs the same care as ordinary login.
School
A school portal authenticates learners, parents, teachers and administrators but gives each role different abilities. A teacher may capture marks for assigned classes, while a learner may only read personal results. Hiding a menu item is not enough; the server enforces the role on every request.
Member
A member area keeps saved articles, notes and progress connected to the correct person. Session expiry limits the damage of an unattended device, while logout invalidates access. Sensitive actions can request the password or another factor again before proceeding.
A fictional user may view 3 of 10 documents. How many documents must the server deny to that user?
Trace the explanation
10 − 3 = 7 denied documents. The check must apply when each resource is requested, including through a manually constructed URL or API call.
Source and further reading: cheatsheetseries.owasp.org
Why should a forgotten password not simply be emailed back to you?
A well-designed password system stores a verifier rather than a recoverable copy of the password. Recovery gives the user a controlled way to set a new secret.
A reset token needs an expiry, restricted use and appropriate protection. Resetting access is a security operation, rather than a special case where normal safeguards can be skipped.
Password recovery is another way into the account
A reset link must be treated as a temporary secret. A secure flow limits its use and lifetime, checks it on the server and avoids revealing more account information than necessary. Making the normal password strong does little good if the recovery route is easy to hijack.
After login, a session can expire or be revoked. The interface should recognise that state and ask the user to sign in again without claiming a protected save succeeded. Before retrying a payment or booking, reconcile any uncertain earlier outcome so a session interruption does not create duplicates.
Does checking 'logged in' only when the page opens protect every later operation?
No. Sessions can change, and callers can send requests without using that page. Each protected server operation needs appropriate authentication and authorisation checks.
Trace identity from login form to protected record
The credentials begin in an HTML form and travel through an HTTPS request. A protected API validates the session and permission before trusted code queries the database. That complete path explains why hiding a button in the browser is never sufficient security.
Frequently Asked Questions
Questions about Authentication Explained Simply
Is authentication the same as authorization?
Authentication checks who you are. Authorization checks what you are allowed to do.
Why do some systems use OTPs?
An OTP adds another proof that the person logging in is really you.
Why should websites not store my password in plain text?
If a database is stolen, readable passwords can be used immediately on that site and anywhere else the same password was reused. Secure systems therefore do not store the password itself. They store a slow cryptographic hash with a unique salt so the original password cannot simply be read back from the database.
That is why a well-designed login system can still check your password without ever keeping a copy of it in plain text.
What is multi-factor authentication?
Multi-factor authentication requires another proof in addition to the password, such as a one-time code from an app or SMS, a security key, or a biometric check. A stolen password alone is then not enough to sign in.
This matters because passwords leak through phishing, reuse and data breaches. The second factor protects the account even when the password is no longer secret.
What is the difference between a session cookie and a token?
Both can represent an authenticated session after you sign in. Their exact format and validation model differ, but the shared idea is that the browser or app presents temporary proof instead of resending the password on every request.
That temporary proof is why you can move between pages without typing your password again, and why signing out or waiting for expiry matters on shared devices.
Why do sessions expire?
Expiration limits how long stolen or abandoned session credentials remain useful. If someone gains access to an open laptop or a copied session token, a short lifetime reduces the damage window.
It also protects shared and unattended devices: after a period of inactivity the system asks you to prove who you are again before continuing.
A user changes a booking ID in the address bar. What must the server check before returning the booking?
One reasoned response
Check that the authenticated user is entitled to that specific booking. A valid login and a valid booking number do not by themselves establish ownership or permission.
Source and further reading: cheatsheetseries.owasp.org
Authentication is more than a login form
Authentication checks who or what is making a request. Authorisation checks what that identity is allowed to do. A person can be correctly signed in and still have no permission to view another user's booking or change an administrator setting.
A safe request-handling outline
// Illustrative pseudocode, not a drop-in security implementation
identity = validateSessionOrToken(request)
if identity is not authenticated:
return 401
if not userCanAccess(identity, requestedResource):
return 403
return requestedResource
The example separates identity validation from the permission check. Real systems must use framework-supported session or token validation, protect secrets, enforce HTTPS, prevent session fixation, apply rate limits where appropriate, and log security events without recording passwords or tokens. Never trust a user ID supplied by the browser as proof that the user owns that account's data. Check ownership and permissions on the server for every protected resource.
Sources
Sources and further reading
A closer lookA signed-in user may still lack permission
A member signs in successfully and changes a booking identifier in a URL. The server must still verify that the requested booking belongs to an account the member may access.
Work through the distinction
Authentication establishes identity. Authorisation checks the action and resource. Perform the ownership or permission check on every relevant request; hiding a link does not enforce access control.
What prevents access to another member's booking?
Choose an answer to see feedback. You can try again.
Show the answer and explanation
A server-side resource permission check. Authentication establishes identity. Authorisation checks the action and resource. Perform the ownership or permission check on every relevant request; hiding a link does not enforce access control.