Authentication

Back when one person used one computer, nobody needed this. Whoever sat at the keyboard owned the machine, so there was no question to ask. Moving services onto the web changed that. The party on the other side of the screen is invisible, thousands of them arrive at the same address, and some of them are there to open documents that aren't theirs.

Pagedeck ran without it early on. Theo built an internal tool for company documents and the whole team shared a single password. It was convenient, and it cost something. One day a meeting note was wiped and nobody could tell who had done it, because every session had arrived as the same account. There was also no way to check whether an intern who had left three months earlier could still get in.

Authentication solves this by asking each person for something only they have. Whoever wants in presents something they alone know or alone possess, and the server compares it against a value stored in advance. When it matches, everything that follows carries a name. Being able to say who deleted the note is the first thing this step buys you.

Authentication runs in four stages — enroll, present, compare, keep. People experience only the second; the rest happens on the server.

1. Enroll. When an account is created, the value you'll compare against later goes into storage. Passwords are not stored as written but as a hashed value. Hashing is a one-way calculation, so even when the account table leaks wholesale, what's written there isn't the password but a mangled version of it.
2. Present. The person types an ID and a password on the login screen. That leg travels only over an encrypted connection, because otherwise anyone sharing the cafe Wi-Fi can read the value straight off the wire.
3. Compare. The server mangles what it received the same way and matches it against what it stored. It also counts failures here. Automated tools try hundreds of guesses a second, so a rule that locks the account after five consecutive misses does more work than password length does.
4. Keep. On a match the server issues a token. The browser carries that token and attaches it to every request so nobody has to log in again, and the server checks the token instead of looking the account up each time. JWT is the format for packing that token into one signed string.

You don't have to build all four yourself. OAuth is the standard for borrowing permission without handing over a password — press "sign in with Google" and what Pagedeck receives is not a Google password but a pass saying it may read a name and an email address. Store no passwords and there are no passwords to leak.

Any service that shows different things to different people needs it, without exception. The choice isn't whether but how strong. A password alone covers free-plan users, while an admin console — where one cracked account opens everything — gets multi-factor authentication (MFA) on top. MFA asks for something you have in addition to something you know, so a leaked password leaves the account standing as long as the phone isn't in the attacker's hand. Enterprise buyers ask for something else again. Single sign-on (SSO) lets one company login carry across every attached service, which from the buyer's side means that closing one account when someone leaves closes all of them.

It stops at two places. First, authentication answers only who. Whether that person may do what they just asked for is a separate question that authorization answers. A screen where any logged-in user can open anyone's document isn't missing authentication; it has authentication and nothing else.

Second, once you're through, the system trusts a token. It won't ask again while that token is valid, so whoever steals it gets in without knowing the password. That's why teams re-prompt before sensitive actions, keep token lifetimes short, and move toward zero trust, where sitting on the internal network is not a reason to skip the check.

"This API has authentication but no authorization check. Log in at all and you can open anyone's document."

The gate asked who you are and never asked whether the document is yours.

"The customer wants SSO. They want to manage the accounts from their own system."

A request to hand account control to the buying company, and usually a contract term.

"Admin accounts can't get in without MFA now."

One extra check was added, but only on the accounts with the most reach.

Pagedeck reworked its authentication ahead of an enterprise deal Grace was closing. The buyer's security questionnaire asked how employee accounts were managed and when departing employees lost access, and the honest answer at the time was that someone did it by hand. It took Theo six weeks to add SSO and put MFA on the admin console.

Account handling wasn't the only thing that changed. Once accounts mapped one-to-one onto people, the record of who opened which document became usable material on its own. What Sofia attached to her reply to the buyer was that record rather than a policy document.

The most common belief is that a more complicated password is a safer one. Every signup screen demands capitals and symbols, so complexity looks like the heart of the matter. But accounts are rarely lost to someone guessing; they're lost to passwords leaked from another service and replayed here. Complexity rules do nothing against that path. Tighter rules often make it worse, because people settle on one combination that barely satisfies the rule and reuse it everywhere. The day any one of those services leaks, the rest open with it.

Reading authentication as a login-screen topic is the other frequent miss, and it's understandable — the login screen is the only version most people meet. The same step runs where no person is present. When a payment provider's server reports a result back to Pagedeck, or an internal script pulls data out, each one gets checked first. Cover the screen and leave that side empty and the login page holds fine while a path stays open for anyone who knows the address.