---
{
  "title": "Authentication",
  "summary": "Understand how authentication verifies an account, how login sessions work, and why recovery and multifactor methods matter.",
  "topic": "foundations",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: An Introduction to Information Security",
      "url": "https://csrc.nist.gov/pubs/sp/800/12/r1/final"
    },
    {
      "title": "OWASP: Authentication",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## 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.](/diagrams/authentication.svg)

## 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.