Sesjonshåndtering og JWT-er

Tradisjonelt innebærer økter at serveren oppretter en unik «session ID» for en bruker etter innlogging. Denne ID-en lagres på serveren.

Deretter sender serveren denne session-ID-en til nettleseren, vanligvis i en informasjonskapsel. Nettleseren sender automatisk informasjonskapselen tilbake med hver påfølgende forespørsel, slik at serveren kan identifisere brukeren.

JSON Web Tokens (uttales «jot») er et moderne alternativ til tradisjonelle økter. De er selvstendige, kompakte og digitalt signerte informasjonsbiter.

I stedet for at serveren lagrer øktdata, lagrer JWT-er brukerspesifikk informasjon direkte i selve tokenet.

En JWT består av tre deler, atskilt med punktum: Header, Payload og Signature.

Header inneholder vanligvis to felt:

• alg: Algoritmen som brukes til å signere tokenet (for eksempel HMAC SHA256 eller RSA).
• typ: Typen token, som vanligvis er «JWT».

Payload inneholder «claims» – utsagn om en entitet (for eksempel en bruker) og ekstra data. Claims kan være:

• Registered Claims: Standardclaims som iss (utsteder), sub (subjekt) og exp (utløpstidspunkt).
• Public Claims: Egendefinerte claims som du definerer, men registrerer i IANA-registeret for JWT.
• Private Claims: Egendefinerte claims som partene blir enige om, og som ikke er offentlig registrert.

Signature opprettes ved å ta den kodede Header-delen, den kodede Payload-delen, en hemmelig nøkkel og algoritmen som er angitt i headeren, og deretter signere dem.

Denne signaturen er avgjørende! Den bekrefter at avsenderen av JWT-en er den den utgir seg for å være, og at meldingen ikke har blitt endret underveis.

Her er et typisk forløp:

1. Brukeren logger inn med legitimasjon.
2. Serveren bekrefter legitimasjonen og oppretter en JWT.
3. Serveren sender JWT-en tilbake til klienten.
4. Klienten lagrer JWT-en (for eksempel i lokal lagring eller en informasjonskapsel).
5. Ved påfølgende forespørsler sender klienten JWT-en (vanligvis i en Authorization-header).
6. Serveren bekrefter JWT-signaturen og utløpstidspunktet før forespørselen behandles.

Fordeler:

• Tilstandsløs: Servere trenger ikke å lagre øktdata, noe som gir bedre skalerbarhet.
• Desentralisert: Token kan bekreftes av enhver server som har den hemmelige nøkkelen.
• Mobilvennlig: Enkel å bruke på tvers av ulike klienter (nett og mobilapper).

Vurderinger:

• Lagring: Hvor token skal lagres sikkert på klientsiden.
• Tilbakekalling: Det er vanskeligere å tilbakekalle et aktivt token før det utløper.
• Størrelse: Kan være større enn en enkel session-ID.

Godt jobbet! I denne leksjonen har du lært om:

• Formålet med nettøkter for å opprettholde brukerkontekst.
• Hvordan tradisjonelle økter bruker lagring på serversiden og informasjonskapsler.
• Strukturen (Header, Payload, Signature) og funksjonen til JSON Web Tokens (JWT-er).
• Arbeidsflyten for bruk av JWT-er til autentisering.
• Viktige fordeler og vurderinger når du velger JWT-er for applikasjonene dine.

Deretter skal vi se nærmere på hvordan du beskytter ruter og API-endepunkter ved hjelp av Next.js Middleware!