Authentication & authorization

A school platform has students, teachers and parents. Students see their homework and grades; teachers enter grades for their classes; parents see their own children's grades. Every request answers two separate questions:

Both matter, but they fail differently. Authentication failures are usually loud: credential stuffing, phishing, stolen sessions. Authorization failures are quiet: the request is from a real, logged-in user, and the server simply forgets to check that the record belongs to them. In the 2025 OWASP Top 10, broken access control is ranked first, and every application in its data set had some form of it; authentication failures rank seventh.

This page follows a request from login to the data: storing passwords, remembering a login with sessions or tokens, delegating login and access with OAuth and OpenID Connect, deciding permissions, and enforcing them on every record. Encrypting the connections and the stored data is Encryption in transit & at rest.

Passwords are never stored, and never stored encrypted: anything that can be decrypted can be stolen and decrypted. The platform stores a hash, a one-way function of the password, and at login hashes the attempt and compares. Two details make that safe:

• A salt, a random value stored per user and mixed into the hash, so identical passwords produce different hashes and precomputed tables are useless.
• A deliberately slow algorithm. Fast hashes like SHA-256 let an attacker with a stolen table test enormous numbers of guesses per second. A password hash is designed to cost time and memory on every guess.

With PBKDF2 at 600,000 iterations, every guess costs 600,000 HMAC computations instead of one. A login pays that once, in a fraction of a second; an attacker pays it for every guess in a dictionary.

The rules users see changed too. Current guidance:

• Length: at least 15 characters when a password is the only factor, 8 when it is one of several; accept at least 64.
• No composition rules ("one digit, one symbol") and no forced periodic changes, only a change when there is evidence of compromise.
• Block known passwords: compare new passwords against lists from earlier breaches and common choices.

The strongest step is a second factor, and the strongest factors are phishing-resistant: passkeys (WebAuthn) are bound to the site's real domain, so a look-alike phishing site can't use them.

After login, the platform must recognize the user on every later request without asking for the password again. Two designs dominate:

• A server-side session: the server stores "session 7f3a… belongs to teacher 1042" and gives the browser only that random ID in a cookie.
• A self-contained token, usually a JWT (JSON Web Token): the server signs a small document of claims (who, which roles, until when) and the client sends it back; any service with the key can check the signature without a lookup.

Anyone holding a signed JWT can read it; the signature prevents changes, not reading, so it must hold nothing secret. A service that accepts it must check the signature with an algorithm it chose itself (never the one the token names, which an attacker can set to none), and check iss, aud and exp.

Most systems combine them. Access tokens live minutes, and a longer-lived refresh token gets new ones and can be revoked centrally. Browsers keep session IDs and tokens in cookies marked Secure, HttpOnly and SameSite, never in local storage that any injected script can read. Session IDs need at least 64 bits of randomness and must change at login, so an attacker can't plant one beforehand (Stateless services & sessions).

Refresh tokens are long-lived, so they are worth stealing. With refresh token rotation, every refresh returns a new refresh token and invalidates the old one. If a stolen token is used, either the thief or the real client later presents one that is already invalidated; the server can't tell which, so it revokes the active refresh token and the user must sign in again.

The school wants parents to sign in with accounts they already have, and a homework-planner app to read a student's assignments without ever seeing the student's password. Both use OAuth 2.0, which lets a user grant an application limited access through an authorization server that issues tokens. The recommended flow is the authorization code flow with PKCE:

Two older OAuth shortcuts should no longer be used: no implicit grant, which returned tokens in the browser address, and no password grant, where the app collects the user's password itself. PKCE is mandatory for apps that can't keep a secret, such as mobile and single-page apps.

OAuth alone answers "what may this app do", not "who is the user". OpenID Connect adds that: alongside the access token, the login server returns an ID token, a signed JWT saying who logged in (sub), at which provider (iss), for which app (aud). "Sign in with" buttons use it. Treating an access token as proof of login is a known mistake: a token issued to another app says nothing about who logged into yours.

Now the platform must decide what each user may do. The simplest model is role-based access control (RBAC): users get roles, roles get permissions. "Teachers may edit grades" is one line. But the real rule is "teachers may edit grades of students in the classes they teach, until the term closes", and roles alone can't express which class or which term. Three models, each adding what the previous one can't say:

Google's Zanzibar is the best-known large relationship-based system: it stores permissions as relationships, and handles trillions of access-control entries and millions of checks a second, 95% of them in under 10 ms. Most applications combine all three: roles for coarse permissions, relationships for ownership and sharing, attributes for conditions like time.

Dana is logged in and opens Leo's grades at /students/48213/grades. She changes the number to 48214 and presses Enter. If the server only checks that the caller is a logged-in parent, Dana now sees another child's grades. This is broken object-level authorization, also called an insecure direct object reference, which OWASP ranks first among API security risks:

The rules that prevent it:

• Deny by default. Every endpoint is closed unless a rule allows it.
• Check the record, not just the role, in every function that takes an ID from the client, including writes and deletes.
• Enforce on the server. Hiding a button in the app protects nothing; the API is reachable directly.
• Authenticate at the edge, authorize near the data. The gateway verifies tokens once (Reverse proxies & API gateways); each service decides on its own records, possibly by asking a central policy service.
• Random IDs help, but don't fix it. Unguessable IDs slow an attacker down; only the check stops one.

Finally, keep permissions small and visible. Give each token the narrowest scope it needs, log every denied request, and alert on bursts of them: a user receiving hundreds of 403s on sequential IDs is someone probing for exactly this flaw.