Every time you log in to a website, a process takes place that you never see but entirely depend on. Not just "the password matched." But: how does the site know it's still you on the next page? And the page after that? And tomorrow?
That's what authentication actually is. Not a button. An ongoing system for proving identity and keeping track of who is who.
Authentication versus authorisation
The two concepts are constantly confused. Authentication is who you are. Authorisation is what you're allowed to do.
You authenticate once when you log in: the system verifies your identity. Then every individual action — pressing publish, editing data, deleting a file — is authorised against what your account actually has permission to do.
A complex app might have dozens of authorisation rules. A simple blog might have two: editors can write, visitors can read. But authentication — the process of understanding who you are — is always the foundation.
How modern token-based authentication works
The old way of tracking logged-in users was sessions: the server stored a record in its database that "session 4829 is Stefan Sånnell." Every page load queried the database. Scale that to millions of users and it starts to strain.
Modern apps solve this with tokens, usually JWT — JSON Web Tokens. The principle is different: instead of the server remembering that you're logged in, you carry proof with you.
When you log in, the server creates a token: a cryptographically signed string containing your user ID and a timestamp. The signature can't be forged without the server's secret key. The token is then stored in your browser.
With every subsequent request, the token is sent along. The server only verifies the signature: does it check out mathematically and hasn't it expired? No database query needed. It's fast, scalable, and works even if you have ten servers instead of one.
OAuth: log in without a password
You've seen it thousands of times: "Sign in with Google." That's OAuth.
OAuth is a protocol for delegating identity verification to a trusted third party. Instead of an app handling your password, Google handles it. The process: you click the Google button, your browser is sent to Google's login page, Google asks whether you approve the app getting access to your email address, you approve, and Google sends a temporary credential back to the app which creates your account.
You've never given the app your Google password. The app doesn't even know what it is. If the app gets hacked, your Google account is intact. That's why OAuth won.
Row Level Security: safety in the database
A pattern Supabase popularised is placing security logic directly in the database. Row Level Security, RLS, means every database row can have rules for who is allowed to read or write it.
The principle is that security sits as close to the data as possible, not just in your frontend or API code. Even if a bug in your application code would allow an incorrect request, the database blocks it if the RLS rule doesn't match.
It's a deeper security mindset: you assume errors can occur and build the database to handle them. Fundamental, but important to understand when you start working with user data.