Designing Authentication: Proving Who You Are

A library card for a website, and a stolen laptop

Rohit, a class 12 student, uses PadhaiPal, a learning website, every evening. One afternoon his laptop is stolen from a bus while he's still logged in. That evening he has also forgotten his password, and his younger sister wants to "just use Sign in with Google." (Rohit, PadhaiPal, Zoya and every incident here are made up for teaching.)

Zoya designs PadhaiPal's login system. Her first principle comes from the school library. The librarian checks your card before lending a book, but the card doesn't let you open the staff cupboard. Websites need the same two separate checks:

• Authentication asks, "Who are you?"
• Authorization asks, "May you do this?"

A successful login must never automatically grant access to every account, file or admin action.

A session is a limited record of one successful login. The design covers registration, login, logout, account recovery and session management. The architecture is a proposal, not the implementation of a named company.

In 30 seconds, as an architect would frame it: "One identity service owns proof of identity. Users get a stable internal ID, passwords are stored as salted Argon2id hashes, and browsers get an opaque, revocable server-side session in a Secure, HttpOnly cookie. Recovery uses short-lived, single-use tokens stored only as digests and consumed atomically with the password change. MFA raises confidence, OIDC handles external sign-in with issuer-plus-subject identity, and authorization is checked separately at every resource. I'll state the revocation delay the design actually gives."

1. "Where do we keep his password?": what to store

Requirements. Email verification, password changes, multiple devices and optional multi-factor authentication (MFA), which means proving identity with more than one kind of evidence. Sensitive changes may need a fresh check even inside a valid session.

Correctness beats convenience. If the identity store is down, a new login fails safely. Existing sessions may continue only under a deliberate validation and revocation policy.

Give each person a stable internal user ID. Rohit's email can change. Store normalised lookup values under a documented email policy, and don't assume every email provider handles dots or capital letters the same way.

The database never holds the original password. A password hash is a one-way check. It is not an encrypted password the application could recover.

• Use a maintained library with a salted, deliberately expensive password-hashing function. OWASP recommends Argon2id for new systems.
• Plain SHA-256 is unsuitable, because it's far too fast: an attacker with a leaked table can try billions of guesses a second.
• Store the algorithm parameters with each hash, so they can be upgraded silently at the next login (OWASP password storage guidance).

2. "He logs in every evening": login and sessions