What Is Authentication?

These three terms get conflated constantly, even by developers, but they answer three completely different questions.

Identification is a claim about who you are. Entering a username or email is essentially saying, “I am this person.” At this stage, the system has received an identity claim, but it has not yet verified it.

Authentication is proving that the identity claim is genuine. This might involve supplying a password, entering an OTP, using a fingerprint, or presenting another valid authentication factor.

Authorization comes after authentication and answers a different question: now that the system knows who you are, what are you allowed to do?

For example, an authenticated user might be authorized to view their own account but not access an administrator's settings.

A concrete flow makes this clear: a login form's username field provides the identification claim, the password provides authentication evidence, and the check the application performs before allowing that authenticated user to open /admin/dashboard is authorization.

Critically, these are independent failure points. An application can have flawless authentication making it impossible to log in as someone else, while still having completely broken authorization, where any authenticated user can access the admin panel. The reverse is also possible: an application might correctly enforce authorization rules while having weaknesses in how users authenticate.

A simple way to remember the distinction is:
Identification → Who do you claim to be?
Authentication → Can you prove it?
Authorization → What are you allowed to do?

The most common authentication mechanism by far is password-based authentication: a user submits a username or email and a password, and the server verifies the password against a stored credential.

Done correctly, the server does not store the user's plaintext password. Instead, it stores a one-way, salted password hash:

if (Hash::check($request->password, $user->password_hash)) { 
    // authenticated — proceed to establish a session 
}

Hash::check() uses the information contained in the stored hash including the salt, hashing algorithm, and its parameters to verify the submitted password against the stored credential. The plaintext password is not stored in the database.

This means that even if an attacker obtains the password database, they do not immediately receive everyone's plaintext passwords. However, password hashes can still be subjected to offline cracking, particularly when users choose weak or reused passwords. That attack path is exactly what Lesson 3.2 covers.

Password-based authentication has a fundamental structural weakness: the security of the credential ultimately depends on a secret that a human must choose, remember, and protect.

That creates a large attack surface: weak passwords, password reuse, credential stuffing, phishing, password spraying, and stolen credentials can all undermine an otherwise correctly implemented authentication system.

Never store passwords. Store password hashes designed specifically for password verification and resistant to offline cracking.

A growing alternative to passwords removes the shared-secret problem rather than trying to manage it better.

Magic links are a simple form of passwordless authentication: instead of asking for a password, the application sends the user a one-time login link, typically by email. The link contains a short-lived credential that allows the user to authenticate. This eliminates password storage and password reuse, but it does not automatically make authentication phishing-resistant an attacker may still be able to trick a user into interacting with a malicious login flow.

WebAuthn and passkeys go further by using public-key cryptography. During registration, the user's authenticator generates a public/private key pair. The private key remains protected by the authenticator and is never exposed to the server; depending on the platform, the credential may also be securely synchronized across the user's devices. The server stores the corresponding public key.

During login, the server generates a unique challenge and sends it to the authenticator. The authenticator verifies that the request comes from the appropriate site and uses the private key to create a cryptographic signature over the challenge. The server verifies that signature using the stored public key.

No password or private key needs to be transmitted to, or stored by, the server.

This makes WebAuthn/passkeys phishing-resistant by design. The credential is cryptographically bound to the legitimate website's origin. A fake login page hosted on a look-alike domain cannot simply collect the user's passkey and replay it against the real site, because the authenticator will not produce a valid assertion for the attacker's origin.

Multi-Factor Authentication (MFA) means requiring two or more authentication factors from genuinely different categories before authentication succeeds. A common example is a password (something you know) combined with a time-based one-time password (TOTP) generated by an authenticator app (something you have).

The security benefit is straightforward: passwords are frequently phished, exposed in breaches, and reused across services. An attacker who obtains a user's password still cannot complete authentication without also compromising the user's second factor.

MFA does not make an account unbreakable. Attackers can target the second factor itself through techniques such as phishing, social engineering, session theft, or weaknesses in account-recovery processes — the real-world bypasses are covered in Lesson 3.5.

What MFA does provide is defense in depth. A stolen password alone is no longer sufficient to authenticate, meaning an attacker must overcome an additional, independent security barrier.

Authentication flaws isn't one login form it's a family of related flows, and each one is its own attack surface. That's exactly why Lesson 3.7's testing methodology treats them separately.

Registration creates a new account and establishes its initial credentials and identity data.

Login performs the standard authentication check, verifying that the user can satisfy the application's authentication requirements.

Password reset, or account recovery more broadly, lets a user regain access without their original credential. Because this flow provides an alternative path into an account, it must be protected to the same standard as normal login.

MFA enrollment and verification establish and subsequently verify additional authentication factors. Weaknesses in either flow can undermine the protection MFA is supposed to provide.

Session establishment occurs after successful authentication, when the application creates the session state, token, or cookie that represents an authenticated user. If this state is improperly generated, stored, or handled, an attacker may be able to bypass authentication even when the login check itself is secure.

Logout should invalidate the relevant authenticated session or credential so that it can no longer be used to access protected resources.

A real application is often only as secure as the weakest authentication flow. A login page with strong password hashing and enforced MFA can still be fully compromised through a poorly designed password-reset flow that was never held to the same security standard.

The key testing mindset is therefore:
Don't ask “Is login secure?” Ask “Can I reach an authenticated state through any path that the application provides?”