Authentication

What authentication actually proves

Authentication checks evidence that someone, or something, controls an identity. Typing a username identifies the account being claimed. Supplying an accepted authenticator provides evidence for that claim. Neither step automatically establishes the person's legal identity, intentions, or permission to perform a particular action.

For a beginner, it helps to separate three questions: Which account is this? What evidence supports that claim? What may this account do? The third belongs to Authorization. A successful login should never become a blanket permission to view every record in an application.

From login to an active session

Consider a fictional employee called Maya signing into a support portal. She enters her account name, completes the configured authentication challenge, and receives a session. The browser can then send a session credential with later requests. The application checks the session instead of asking Maya to repeat the entire login every time she opens a ticket.

That convenience introduces another security boundary: someone who steals a usable session credential may be able to act as Maya without knowing her password. Learn about Sessions and cookies alongside login controls; they protect different parts of the same journey.

Authentication establishes an account session; authorization then checks access to each requested resource. Open full-size diagram ↗

Factors and their limits

An authentication factor is a category of evidence. A password is something you know. A security key is something you have. A biometric characteristic is something you are, although its role in a particular implementation needs careful explanation: on many devices it unlocks a local authenticator rather than being sent to the website.

Two passwords remain the same category. Multifactor authentication combines different categories, but different methods resist different attacks. An attacker might trick a person into revealing a one-time code. A stronger method can bind authentication to the intended service, reducing that particular risk. No method makes a compromised laptop harmless.

The recovery route matters

Imagine Maya uses a strong authenticator, but the help desk replaces it whenever a caller knows her job title. The normal login is strong; recovery has become the easier route into the account. Enrollment, replacement, recovery, and removal therefore deserve the same design attention as the sign-in screen.

For an application review, draw those routes before choosing a login product. Ask who can register a new authenticator, how an existing user is notified of a change, and what happens to active sessions after suspected compromise. These questions reveal gaps that a screenshot of the login page cannot show.

A useful first investigation

In a training application you own, sign in on two browsers. Change the password in one, then check whether the other session still works. Record the observed behavior instead of assuming a password change revokes every session. The appropriate response depends on the product's policy and implementation.

If investigating a real suspicious login, preserve the relevant events and follow the organization's response process. A failed attempt is evidence of an attempt, while a successful authentication still needs context: device, time, subsequent actions, and the account's expected use.

Continue with Authorization to understand resource access, and Multifactor authentication to compare evidence used at sign-in.