Curiosity first
Why do websites need to check who you are?
Authentication is how a system confirms your identity. When you log into a website, the system checks that you are allowed to access that account.
Let’s explain it simply.
What you will learn on this page
- What authentication means: proving which identity is making a request through accepted evidence.
- Why login matters: private records and personal actions must remain separated between users.
- How sessions and tokens help: they represent a successful check for a limited time without resending the password on every action.
- Why access still needs protection: server-side authorisation decides what the authenticated identity may read or change.
The hotel key example
A hotel gives you a key card for your room. The key proves you are allowed inside that room, but not every room in the hotel. Authentication works in a similar way.
Login and tokens
You enter a username and password. If correct, the system may give your browser or app a token. That token is used when making future requests.
Why authentication matters
Without authentication, private information could be exposed. Banks, emails, school portals and company systems all need strong access control.
Where you will see this in real life
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 rather than 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.
Signing in proves identity for a limited context
Authentication starts a session; authorisation still checks each protected operation. Password storage, multi-factor verification, recovery, expiry and logout all belong to the same security workflow because attackers look for the weakest path.
Identity and access
What actually happens when you sign in
Authentication answers “who are you?” while authorisation answers “what are you allowed to do?” A typical sign-in sends credentials over HTTPS. The server compares the submitted password through a secure password-hashing process rather than storing readable passwords. After a successful sign-in, the server issues a session cookie or token. Later requests present that proof so the application does not ask for the password on every click.
See it in real life
A member opens a dashboard. The browser sends its secure authentication cookie with the request. The server validates the session, loads the member identity and then checks permissions before returning private information. An admin screen adds another authorisation check because being a signed-in member does not automatically make someone an administrator. Those checks belong on the server even if the menu also hides links in the browser.
Why this matters
Authentication failures can expose entire accounts, which is why small design choices matter: HTTPS, password hashing, expiration, secure cookies, rate limiting, multi-factor authentication and careful password-reset flows all reduce different risks. Email verification and password reset links should also expire and be difficult to guess.
A common misunderstanding
Hiding a button is not security. A user can still send a request manually. Real authorisation must be enforced by the server handling the operation, because the server is the part of the system that ultimately owns the protected data or action.
Questions people actually ask
Useful questions about this topic
Why should websites not store my password in plain text?
If a database is stolen, readable passwords can be used immediately. Secure systems store a slow cryptographic hash with a salt so the original password is not simply sitting in the database.
What is multi-factor authentication?
It requires another proof in addition to the password, such as a one-time code or security key. A stolen password alone is then not enough to sign in.
What is the difference between a session cookie and a token?
Both can represent an authenticated session. Their exact format and validation model differ, but the key idea is that the browser presents temporary proof instead of resending the password.
Why do sessions expire?
Expiration limits how long stolen or abandoned session credentials remain useful and reduces risk on shared or unattended devices.
Authentication is really a chain of checks, not just a login form
When you enter an email address and password, the website should not simply compare your password with readable text stored in a database. Well-designed systems store a one-way password hash, then hash the password you submit and compare the results.
After login, the site also needs a way to remember that you have already proved who you are. That may be a secure session cookie or token. Every protected request then checks that session before returning personal information or allowing an action.
Password resets, multi-factor authentication and account lockouts are part of the same security story. A login page can look simple, but the real work is making sure identity cannot be easily guessed, stolen or reused by someone else.
Follow the connectionTrace 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.
Go deeperWhat a secure sign-in is actually proving
Authentication answers “who are you?” while authorisation answers “what are you allowed to do?”. A secure system does not normally store a password in readable form. It stores a salted password hash. At sign-in, the submitted password is processed with the same password-hashing algorithm and the result is compared. If it matches, the system can create a session or issue a token that represents the authenticated user.
That token or session still needs protection. Expiry times limit how long stolen credentials remain useful, HTTPS protects them in transit, and multi-factor authentication adds another proof beyond the password. Email verification proves control of an email address, but it is not the same as proving a person’s legal identity. Good authentication is therefore a chain of controls rather than a single login form.
Real-World DepthA Login Is A Security Workflow
When you enter an email address and password, the website should not simply compare your password with readable text stored in a database. A well-designed system stores a one-way password hash with a unique salt. During login it hashes the password you entered using the same method and checks whether the result matches. That reduces the damage if the password database is ever exposed.
After successful authentication, the application normally creates a session or issues a token so that you do not have to send your password with every click. The browser then presents that session proof on later requests. The server still has to authorise each protected action: being logged in proves who you are, but it does not automatically mean you may edit another person’s profile or see an administrator page.
Password resets and email changes deserve the same care. A reset link should be random, expire after a limited time and become invalid after use. Changing an email address may require verification because email often becomes the route for future password recovery. Authentication is therefore a chain of controls, not one login button.