Varje gång du loggar in på en webbplats sker en process du aldrig ser men helt beror på. Inte bara "lösenordet stämde." Utan: hur vet sidan att det fortfarande är du på nästa sida? Och sidan efter det? Och imorgon?
Det är det autentisering faktiskt är. Inte en knapp. Ett pågående system för att bevisa identitet och hålla reda på vem som är vem.
Autentisering mot auktorisering
De två begreppen blandas ihop konstant. Autentisering är vem du är. Auktorisering är vad du får göra.
Du autentiserar dig en gång när du loggar in: systemet verifierar din identitet. Sedan auktoriseras varje enskilt handling — trycka publicera, redigera data, radera en fil — mot vad ditt konto faktiskt har tillåtelse att göra.
En komplex app kan ha tiotals auktorisationsregler. En enkel blogg har kanske två: redaktörer kan skriva, besökare kan läsa. Men autentiseringen — processen att förstå vem du är — är alltid grunden.
Hur modern tokenbaserad autentisering fungerar
Det gamla sättet att hålla reda på inloggade användare var sessions: servern sparade en post i sin databas om att "session 4829 är Stefan Sånnell." Varje sidladdning frågade databasen. Skala det till miljoner användare och det börjar slita.
Moderna appar löser detta med tokens, vanligtvis JWT — JSON Web Tokens. Principen är annorlunda: istället för att servern minns att du är inloggad, bär du med dig ett bevis.
När du loggar in skapar servern en token: en kryptografiskt signerad sträng som innehåller ditt användar-ID och en tidsstämpel. Signaturen kan inte förfalskas utan serverns hemliga nyckel. Sedan lagras token i din webbläsare.
Vid varje påföljande förfrågan skickas token med. Servern verifierar bara signaturen: stämmer den matematiskt och har den inte löpt ut? Ingen databasfråga behövs. Det är snabbt, skalbart och fungerar även om du har tio servrar istället för en.
OAuth: logga in utan lösenord
Du har sett det tusentals gånger: "Logga in med Google". Det är OAuth.
OAuth är ett protokoll för att delegera identitetsbevis till en betrodd tredje part. Istället för att en app hanterar ditt lösenord sköter Google det. Processen: du klickar på Google-knappen, din webbläsare skickas till Googles inloggningssida, Google frågar om du godkänner att appen får tillgång till din email-adress, du godkänner, och Google skickar ett temporärt intyg tillbaka till appen som skapar ditt konto.
Du har aldrig gett appen ditt Google-lösenord. Appen vet inte ens vad det är. Om appen hackas är ditt Google-konto intakt. Det är varför OAuth vann.
Row Level Security: säkerhet i databasen
En pattern som Supabase populariserat är att lägga säkerhetslogiken direkt i databasen. Row Level Security, RLS, innebär att varje databasrad kan ha regler för vem som får läsa eller skriva den.
Principen är att säkerheten sitter så nära datan som möjligt, inte bara i din frontend eller din API-kod. Även om en bugg i din appkod skulle tillåta ett felaktigt anrop blockerar databasen det om RLS-regeln inte matchar.
Det är ett djupare säkerhetstänk: du förutsätter att fel kan uppstå och bygger databasen för att klara av det. Grundläggande, men viktigt att förstå när du börjar arbeta med användardata.