Authentication in plain words

Authentication checks who a user is, and authorization decides what that user may do. A person is recognized by a session cookie, a JWT, OAuth or a passkey.

Two questions that get mixed up

When a site gets a sign-in, two different questions appear, and it helps to keep them apart.

Authentication is who are you? It is a check of identity: you typed a password, confirmed a code from an SMS, put a finger on a reader. Like a passport at the gate.

Authorization is what may you do? These are rights: a guest may look, an editor may change the texts, an owner may delete and see the inquiries. Like a pass that opens some doors and not others.

First the server finds out who has come, and then, on every request, it decides whether this person may have what they ask for. We start with the first.

The main question: is sign-in needed at all?

Any sign-in means accounts, and accounts mean duties. You keep other people’s personal data (you have already met the law on it), you answer for a leak, you must be able to restore forgotten passwords, and you must defend against break-ins. For a small business site, a landing page or a blog, sign-in is most often not needed at all: the visitor looks at the page and leaves an inquiry with no account. Sign-in is needed where something is personal: an account area, orders, a closed section, editing by the owner.

A rule that will save months: no sign-in, no sign-in problems. Start without it.

Sessions and cookies

Suppose sign-in is needed. HTTP, as you remember, doesn’t remember you between requests. So after a person has signed in, they must somehow be recognized on every following request. The classic way is a session. The server checks the password, makes a record on its side, “session number …, user Anna”, and sends the browser the number in a Set-Cookie header. The browser stores this cookie and sends it back by itself with every request to this site. The server sees the number and recognizes the person.

A session cookie gets three flags, always:

• HttpOnly: scripts on the page can’t read the cookie, so even if a foreign script gets onto the page (the XSS from the lesson on the DOM), it can’t steal the session;
• Secure: the cookie is sent only over HTTPS;
• SameSite: the cookie isn’t sent with requests started by other sites, which protects against forged requests (CSRF).

Passwords: store what can’t be read

If the check uses a password, the most serious question arises: how do you store passwords? The answer leaves no choice: never as plain text. Databases leak, and people use the same password on many sites, so a leaked password breaks other people’s accounts elsewhere.

What is stored is a hash of the password: the result of an irreversible calculation (you can’t get the password back from a hash, you can only calculate the hash of a guessed password and compare). But not just any hash: a slow one, with a salt:

• a salt is a random addition to each password, so two people with the same password get different hashes, and attacking everyone at once won’t work;
• a slow algorithm (argon2id, bcrypt, scrypt) makes every guess take noticeable time, so trying billions of variants is expensive. Fast hashes such as MD5 or SHA-1 are no good for passwords: billions can be computed a second.

It follows that a service can’t “remind” you of a password: it doesn’t know it, it can only let you set a new one. If a site emails you a forgotten password, it stores passwords as plain text, and that site can’t be trusted. Beyond that: limit the number of attempts, don’t force fussy composition rules, but do check passwords against lists of leaked ones, and encourage a second factor (a code from an app). A detailed list of rules is in the OWASP authentication cheat sheet (the link is in the sources).

Tokens and JWT

For API interfaces and systems made of many servers, a session is awkward: every server has to know about it. So tokens were invented. After sign-in the server issues a signed string that records who you are and until when it is valid, and keeps nothing afterwards. The best-known format is the JWT (JSON Web Token), which has three parts separated by dots: a header, the content and a signature.

Two properties are worth grasping. First, a JWT is signed but not encrypted. The first two parts are just JSON in base64 encoding, and anyone can read them. The signature protects against tampering, not against reading, so no secrets go in a token. Second, a token is valid until it expires, and revoking it early is hard. So the lifetime is kept short, and the token is stored in an HttpOnly cookie. Check it on the diagram: read the contents of a token, swap the role and see what the server says:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQyIiwicm9sZSI6InZpc2l0b3IiLCJleHAiOjE4OTM0NTYwMDB9.

{
 "sub": "user-42",
 "role": "visitor",
 "exp": 1893456000
}

Signing in through a provider: OAuth

Storing passwords is frightening and remembering ten of them is hard, so “sign in with…” appeared: Google, Apple, GitHub, and in some countries a government service such as GOV.UK One Login in the UK or Login.gov in the United States. In Russia the same role is played by Yandex ID, VK ID and the Gosuslugi portal. It all runs on the OAuth 2.0 standard, or more exactly on OpenID Connect, which adds the question “who are you?” to it. (OAuth itself is about something else: it lets one service get limited access to another’s data with your consent, for example an app reading your calendar.)

The idea is that the password is typed only on the provider’s page, and your site gets confirmation from the provider that the person signed in, and (with their permission) a name or an email. You don’t store a password, you don’t invent recovery, and you get the provider’s two-factor protection for free. The price is dependence on the provider and an important legal subtlety: the visitor’s data passes through a third-party operator, so this is processing of personal data, which has to be mentioned in the privacy notice.

Passkeys: signing in without a password

The most modern protection is called a passkey and rests on the WebAuthn standard (FIDO2). At registration the device creates a pair of keys: the public key goes to the site, and the private key stays on the device and never leaves it. At sign-in the site sends a random string, and the device signs it with the private key, after you have confirmed yourself with a fingerprint, a face or the device’s code.

The result: there is no password, so it can’t be spied on, guessed, stolen from a database (the server holds only public keys) or coaxed out on a fake site, because the signature is tied to the real address. Passkeys sync between devices through the password managers of Apple, Google and others. They are still unfamiliar to many people, and a fallback way to sign in is needed, but the future is theirs.

Walk through the four ways step by step and see what can be stolen in each:

Authorization: roles and rights

Once it is clear who has come, the question is what they may do. The simplest and most common method is roles. Each user is given a role (visitor, editor, owner), and each role a set of rights (read, change texts, delete, see inquiries). Hand out as little as possible: the minimum needed for the work.

There is one main rule of authorization: check on the server, on every request. Hiding the “Delete” button from visitors is convenient, but it isn’t protection: a request can be sent without the button, from the console or from a program. If the server doesn’t check rights, the button protects nothing.

Privacy law and sign-in

An email address and a name are personal data. In the EU the GDPR applies to them, and in the United Kingdom the UK GDPR and the Data Protection Act 2018. In short: you need a lawful basis for processing (consent is one; a contract or a legitimate interest can be others), a privacy notice that says what you collect and why, and a contract with each service that processes the data for you. When a provider such as Google or Apple takes part in signing in, say so in the notice, and if the provider is outside the UK or the EEA, the rules on international transfers apply. Several US states have comparable laws, such as California’s CCPA. For comparison, Russia’s law (152-FZ) also asks for consent and a policy, and in addition requires the first recording of Russian citizens’ data to be made on servers in Russia.

This is general information, not legal advice. In the UK the Information Commissioner’s Office (ico.org.uk) explains the rules, and in the EU you can ask your national data protection authority; the European Data Protection Board (edpb.europa.eu) publishes shared guidance.

Practice

You are on a site from the 2022 era. Before you think about how to build sign-in, decide whether it is needed. Ask yourself: what does a visitor do on my site (the main action from the brief), and must they be recognized to do it? For an inquiry through a form, most often not.

If sign-in is needed even for the owner alone, describe three roles and what each may do, choose a way to sign in, and say how passwords are stored (or that there are none). And be sure to mention the law: an email address and a name are personal data (the GDPR), and signing in with Google or by SMS is processing of that data with third-party operators taking part. A lawful basis and a privacy notice are needed.

What was wrong before

Passwords were stored as plain text, then as an unsalted MD5 hash (“enough that it can’t be read”), and at every leak millions of passwords were cracked within hours. “Secret questions” (“your mother’s maiden name”) were guessed or found on social networks. The session number was put right in the address of the page (?sid=...), and a forwarded link handed over somebody else’s account. Basic authentication sent the login and password in the open with every request. Password rules (“eight characters, a digit, a capital and a symbol”) made people invent weak and repeated passwords.

Today’s advice is the opposite: long passwords without fussy rules, a check against lists of leaked ones, a slow hash with a salt, a second factor, and better still passkeys and signing in through a provider. The best solution is not to store passwords at all.