Sessionshantering och JWT:er

Traditionellt innebär sessioner att servern skapar ett unikt "session-ID" för en användare efter inloggningen. Detta ID lagras på servern.

Servern skickar sedan session-ID:t till webbläsaren, vanligtvis i en cookie. Webbläsaren skickar automatiskt tillbaka denna cookie med varje efterföljande förfrågan, så att servern kan identifiera användaren.

JSON Web Tokens (uttalas "jot") är ett modernt alternativ till traditionella sessioner. De är självständiga, kompakta och digitalt signerade informationsdelar.

I stället för att servern lagrar sessionsdata lagrar JWT:er användarspecifik information direkt i själva tokenen.

En JWT består av tre delar, separerade med punkter: Header, Payload och Signature.

Header innehåller vanligtvis två fält:

• alg: Algoritmen som används för att signera tokenen (till exempel HMAC SHA256 eller RSA).
• typ: Typen av token, vanligtvis "JWT".

Payload innehåller "claims" – påståenden om en entitet (till exempel en användare) samt ytterligare data. Claims kan vara:

• Registered Claims: Standardclaims som iss (utfärdare), sub (subjekt) och exp (utgångstid).
• Public Claims: Anpassade claims som du definierar, men registrerar i IANA JWT Registry.
• Private Claims: Anpassade claims som parter har kommit överens om och som inte är offentligt registrerade.

Signature skapas genom att den kodade Header-delen, den kodade Payload-delen, en hemlig nyckel och algoritmen som anges i headern tas och signeras.

Denna signatur är avgörande! Den verifierar att JWT:ns avsändare är den som den utger sig för att vara och att meddelandet inte har manipulerats på vägen.

Här är ett typiskt flöde:

1. Användaren loggar in med sina autentiseringsuppgifter.
2. Servern verifierar uppgifterna och skapar en JWT.
3. Servern skickar tillbaka JWT:n till klienten.
4. Klienten lagrar JWT:n (till exempel i local storage eller en cookie).
5. Vid efterföljande förfrågningar skickar klienten JWT:n (vanligtvis i en Authorization-header).
6. Servern verifierar JWT:ns signatur och giltighetstid innan förfrågan behandlas.

Fördelar:

• Tilståndslös: Servrar behöver inte lagra sessionsdata, vilket förbättrar skalbarheten.
• Distribuerad: Tokenar kan verifieras av alla servrar som har den hemliga nyckeln.
• Mobilvänlig: Enkel att använda med olika klienter (webb, mobilappar).

Att tänka på:

• Lagring: Var tokenar ska lagras säkert på klientsidan.
• Återkallande: Det är svårare att återkalla en aktiv token innan den löper ut.
• Storlek: Kan vara större än ett enkelt session-ID.

Bra jobbat! I den här lektionen har du lärt dig om:

• Syftet med webbsessioner för att bevara användarens kontext.
• Hur traditionella sessioner använder lagring på serversidan och cookies.
• JSON Web Tokens (JWT:er), deras struktur (Header, Payload, Signature) och funktion.
• Arbetsflödet för autentisering med JWT:er.
• Viktiga fördelar och saker att tänka på när du väljer JWT:er för dina applikationer.

Härnäst går vi igenom hur du skyddar routes och API-endpoints med Next.js Middleware!