Jan Mikoláš
Glossary
Authentication
Authentication answers the question “who is this?” It is essential for signing in to an application, but without subsequent server-side authorization it does not grant access to an order, account, or administration interface.
Short definition
Verifying identity is not the same as deciding permission.
During authentication, a subject proves something they know, possess, or are: a password, passkey, one-time code, hardware key, or cryptographic service signature, for example. The application verifies the proof and, based on the result, creates a signed-in session or issues a limited access token. More sensitive operations may require fresh verification or multiple factors.
Authentication does not mean that a subject is automatically permitted to perform an action. A signed-in warehouse employee and an account administrator may both be authenticated successfully, but they do not have the same powers. Every relevant server endpoint therefore follows authentication with authorization for the requested resource, role, tenant, and current context.
What it is used for
For both user access and communication between services
Identity verification is not limited to a password form. Browser applications, APIs, and automated integration processes all need it.
- signing a customer into an account or an operator into online-store administration
- multi-factor verification before changing payment details, a password, or a role
- single sign-on through an identity provider using OpenID Connect
- authenticating a machine client with an access token, client certificate, or another managed credential
- re-verifying identity for a high-risk operation or after a long period of session inactivity
Practical example
Signing an operator in before working with orders
The application loads the account by login name and verifies the submitted password against a securely stored password hash. On failure, it returns a generic error and limits attempts so it does not make account guessing easier. On success, it creates a new session with a rotated identifier; neither the password nor its hash is stored in the session.
The example illustrates only the critical condition. In a real application, it is preceded by input validation, rate limiting, and a consistent response for a nonexistent account. After the session is established, every subsequent order change is still authorized on the server.
if (!password_verify($submittedPassword, $account->passwordHash)) {
throw new AuthenticationFailed();
}
session_regenerate_id(true); // až po úspěšném ověření
$_SESSION['account_id'] = $account->id;How it works
From presenting proof to a verified subject
A well-designed flow separates identity verification, issuance of a credential for subsequent requests, and the later permission check.
- The subject identifies itself It supplies a username, email address, provider identity, or machine-client identifier. Identification is not yet proof.
- It presents an authentication factor This may be a password, passkey, OTP, or signature. The factor should match the value of the account and the risk of the operation.
- The server verifies the proof A password is compared with a hashed value, a token with its expected properties, and an external identity through a verified protocol. Failures are limited and recorded in proportion to the risk.
- A session or token is created The server establishes a revocable session or issues a limited credential for further communication. Its lifetime and protection are designed separately.
- The server authorizes every access The verified identity is matched with current roles, ownership, and policy for the specific resource. This is not a one-off UI step.
Main components
Proof of identity, credential protection, and risk management
Secure authentication is a sequence of steps. No single library can solve a weak password, a leaked session, or overly broad permissions.
Passwords and hashing
A password is neither stored in readable form nor “encrypted for later reading.” The server stores a suitable adaptive hash and uses a safe library function for verification.
Multi-factor authentication
Combines independent types of proof, such as a password and passkey or one-time code. It is particularly important for administrators and highly sensitive changes.
Rate limiting and detection
Attempt limits, a safe recovery flow, and monitoring protect against credential guessing. They should not, however, lock legitimate users out without good reason.
Reauthentication
A risky operation may require fresh proof of identity even during a valid session, such as before changing a password or payout details.
Machine identity
An integration should not share a human password. It uses its own credential, narrow scopes, secret rotation, and a traceable owner.
Benefits and limitations
Stronger login reduces risk, but does not remove the need for careful design
Benefits
- associates a request with a particular user or service for subsequent security decisions
- MFA and reauthentication reduce the impact of a stolen or guessed password
- separate credentials for people and services improve revocation and auditing
- a session or token can be limited by time, purpose, and scope
Risks and common mistakes
- confusing successful login with permission to work with every resource
- storing readable passwords, returning overly precise login errors, or omitting protection against guessing
- treating a signed JWT as safe without validating its context and lifetime
- relying on a hidden frontend button instead of server-side authorization
When it needs more careful design
The strength of verification should match the value of the account and action
An ordinary customer account, internal administration interface, and partner API face different threats and needs. Administration of orders or user roles generally warrants MFA, secure access recovery, session management, and auditing. An automated integration needs its own credential with minimum permissions, not a shared employee account.
Choosing between a cookie-based session, bearer token, and external identity provider is not about one universally best technology. What matters is that the application understands how the credential is passed, can invalidate or restrict it, and performs server-side authorization on every entry path.
What to consider
Verify on the server, prevent attacks, and protect the resulting session
A secure login flow is tested in error and recovery states, not only with a positive form test.
- store passwords with a suitable adaptive hash and never write their values to logs or errors
- use MFA or fresh verification for sensitive accounts and operations according to risk
- limit attempts, design password recovery safely, and return suitably generic errors
- protect the session or token after success, rotate the session ID, and set an expiration
- test that the server still denies an action without the required permission after authentication
Common questions
Authentication in practice
What is the difference between authentication and authorization?
Authentication verifies identity: who sent the request. Authorization decides whether that subject may perform the operation on the specific resource.
Is JWT authentication?
JWT is a token format. It can carry claims created after authentication, but does not explain how the identity was verified or guarantee correct authorization.
Is OAuth 2.0 the same as login?
Not necessarily. OAuth 2.0 provides delegated authorization. OpenID Connect is normally used on top of it for standard identity verification.
Is a strong password enough?
A strong password is only one factor. MFA, attempt limits, a safe recovery flow, and protection of the subsequent session help secure sensitive accounts.
How I approach backends in practice
I design access from identity through to a specific action on data.
In APIs, e-commerce, and internal systems, I connect identity verification with session management, roles, and server-side resource checks.