De to tokens findes for at løse en direkte konflikt: et access token skal sendes ved hver request (så det eksponeres meget), men samtidig vil du have sessioner, der varer længe uden at tvinge hyppige logins. Du kan ikke have begge dele sikkert i ét token — så du deler opgaven op.
Authorization-headeren ved hvert API-kald. Fordi det transmitteres konstant, er et læk sandsynligt; at holde det kort betyder, at et stjålet udløber næsten med det samme.Login ──▶ access (15m) + refresh (30d)
Every API call ──▶ send access
Access expired ──▶ send refresh ──▶ new access (+ rotated refresh)
| Ét langlivet access token | Access + refresh | |
|---|---|---|
| Eksponering | Sendt ved hver request, lever længe → stort tyverivindue | Access kortlivet; refresh sjældent sendt |
| Tilbagekaldelse | Svært (stateless JWT kan ikke af-udstedes) | Tilbagekald refresh token; access dør inden for minutter |
| UX | Hyppig gen-login hvis kort | Forbliver logget ind uden at genindtaste legitimationsoplysninger |
| Skadesradius ved læk | Stor | Lille (access udløber hurtigt) |
httpOnly-cookie, uden for XSS' rækkevidde.Dette er det standard moderne auth-design, og interviewere spørger om det for at se, om du forstår hvorfor, ikke bare hvordan. Den centrale indsigt er afvejningen: statelessness og kort eksponering (access) versus lange sessioner og tilbagekaldelighed (refresh). At få det galt — et langlivet access token, ingen rotation, refresh opbevaret i localStorage — forvandler et enkelt lækket token til en langlivet kontokompromittering. At navngive opdelingen og hvad hvert token giver dig, er hvad en sikkerhedsbevidst ingeniør forventes at vide.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér