Inloggning och generering av JWT

I den föregående lektionen lärde vi oss om användarregistrering och säker hashning av lösenord. Nu är det dags att bygga inloggningssystemet!

Ett inloggningssystem gör det möjligt för autentiserade användare att få åtkomst till skyddade resurser och anpassa sin upplevelse i er SaaS-applikation.

När en användare försöker logga in anger hen vanligtvis ett användarnamn (eller en e-postadress) och ett lösenord. Det grundläggande flödet ser ut så här:

• Klienten (till exempel er mobilapp) skickar inloggningsuppgifterna till servern.
• Servern verifierar uppgifterna mot de lagrade användardata.
• Om uppgifterna är giltiga beviljar servern åtkomst.

När servern tar emot inloggningsuppgifter måste den utföra en viktig kontroll:

1. Hitta användaren med hjälp av den unika identifieraren (till exempel e-postadress eller användarnamn).
2. Hämta det lagrade hashade lösenordet för användaren.
3. Jämför det angivna lösenordet (efter att ha hashas med samma metod) med det lagrade hashade lösenordet.

Lagra aldrig lösenord i klartext! Hasha och salta dem alltid, enligt det vi gick igenom i lektionen om registrering.

Moderna API:er är ofta tillståndslösa, vilket innebär att servern inte kommer ihåg tidigare förfrågningar från samma klient. Det gör API:er skalbara, men skapar en utmaning för användarautentisering.

Hur vet vi att en användare som nyss loggade in fortfarande är autentiserad vid nästa förfrågan, utan att skicka inloggningsuppgifter varje gång?

JSON Web Tokens (JWT) är ett kompakt och URL-säkert sätt att representera anspråk som ska överföras mellan två parter. De passar utmärkt för tillståndslös autentisering.

I stället för sessioner på serversidan utfärdar servern en JWT efter en lyckad inloggning. Klienten lagrar sedan denna token och skickar med den i varje efterföljande förfrågan.

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

Header innehåller vanligtvis två delar:

• typ (typen av token, vanligtvis 'JWT')
• alg (signeringsalgoritmen, till exempel 'HS256' för HMAC SHA256)

Det är ett JSON-objekt som kodats med Base64Url.

Payload innehåller så kallade 'claims' – påståenden om en entitet (vanligtvis användaren) samt ytterligare data.

Claims kan vara:

• Registrerade: Standardfält som sub (subjekt), exp (förfallotid) och iat (tidpunkt då den utfärdades).
• Publika: Anpassade claims som definieras av er, men registreras i IANA:s register för JSON Web Token.
• Privata: Anpassade claims som parterna som använder dem har kommit överens om, till exempel userId eller role.

Exempel på payload:

Signature är avgörande för att verifiera tokenens integritet. Den skapas genom att den kodade headern, den kodade payloaden och en hemlig nyckel bearbetas med algoritmen som anges i headern.

Om någon försöker manipulera headern eller payloaden misslyckas signaturverifieringen, vilket gör token ogiltig. Den hemliga nyckeln är endast känd av servern.

När servern har verifierat en användares inloggningsuppgifter skapar den en JWT. Det innebär att:

1. JSON-objekten Header och Payload skapas.
2. Båda kodas med Base64Url.
3. De sammanfogas med en punkt.
4. Den sammanfogade strängen signeras med en hemlig nyckel och den valda algoritmen för att skapa Signature.

Den slutliga JWT:n är EncodedHeader.EncodedPayload.Signature.

Fullständig JWT-signering kräver ett bibliotek, men vi kan demonstrera Base64-kodningen som en del av att bygga en JWT-sträng. Det säkerställer att token är URL-säker.

Bra jobbat! Ni har lärt er hur ett inloggningssystem fungerar och vilken roll JSON Web Tokens (JWT:er) har i modern, tillståndslös autentisering.

• Inloggning innebär att inloggningsuppgifter verifieras mot hashade lösenord.
• JWT:er ger ett tillståndslöst sätt att hantera användarsessioner.
• JWT:er har tre delar: Header, Payload och Signature.
• Signature säkerställer tokenens integritet.

Härnäst undersöker vi hur ni kan använda dessa JWT:er för att skydda era API-rutter!