Authentication

Authentication is not authorisation

Two words, often shortened to authn and authz, and confusing them is the source of a lot of broken access control. Authentication proves you are the account holder. Authorisation decides whether that account may read this particular record. An application that checks only the first will happily let a logged-in user fetch someone else's data by changing an ID in the URL.

How the session is actually kept

HTTP forgets you between requests, so after a successful login the server issues something the client sends back each time:

• A session cookie pointing at server-side state. Easy to revoke instantly, because the server owns the session record.
• A token, usually a JWT, which carries signed claims and needs no server lookup. Fast and stateless, but it stays valid until it expires — you cannot un-issue one, which is why short lifetimes plus a refresh token are the norm.

Where the token lives matters. localStorage is readable by any script on the page, so a single cross-site scripting flaw exposes it. An HttpOnly cookie is not readable from JavaScript but needs protection against cross-site request forgery. Both are used in production; neither is free.

The rules that hold up

Never store passwords, only hashes from a slow algorithm designed for it — bcrypt, scrypt or Argon2. Never enforce a rule only in the interface: hiding a button stops nobody, because the request can be made directly. Rate-limit login attempts. And treat a second factor as the highest-value addition you can make, since it defeats stolen and reused passwords almost entirely.

Managed providers such as Supabase Auth, Auth0 and Firebase Authentication exist because getting all of this right is genuinely hard. NorthernGo apps use the same approach: .register(), .login(), .getToken() and .logout() sit on top of a managed identity layer, and any app with login must also provide .deleteAccount() — a working account deletion path is required, since GDPR article 17 gives users a right to erasure.