De två tokens finns för att lösa en direkt konflikt: en access token måste skickas vid varje request (så den exponeras mycket), samtidigt som du vill ha sessioner som varar länge utan att tvinga fram täta inloggningar. Du kan inte ha båda säkert i en enda token — så du delar upp jobbet.
Authorization-headern vid varje API-anrop. Eftersom den överförs ständigt är en läcka trolig; att hålla den kort betyder att en stulen sådan löper ut nästan omedelbart.Login ──▶ access (15m) + refresh (30d)
Varje API-anrop ──▶ skicka access
Access utgången ──▶ skicka refresh ──▶ ny access (+ roterad refresh)
| En långlivad access token | Access + refresh | |
|---|---|---|
| Exponering | Skickas vid varje request, lever länge → stort stöldfönster | Access kortlivad; refresh skickas sällan |
| Återkallelse | Svårt (stateless JWT kan inte av-utfärdas) | Återkalla refresh token; access dör inom minuter |
| UX | Ominloggning ofta om kort | Förblir inloggad utan att ange uppgifter på nytt |
| Skadeområde vid läcka | Stort | Litet (access löper ut snabbt) |
httpOnly-cookie, utom räckhåll för XSS.Detta är den moderna standarddesignen för auth, och intervjuare frågar det för att se om du förstår varför, inte bara hur. Den centrala insikten är avvägningen: statelessness och kort exponering (access) mot långa sessioner och återkallbarhet (refresh). Att göra fel — en långlivad access token, ingen rotation, refresh lagrad i localStorage — förvandlar en enda läckt token till en långlivad kontokompromiss. Att namnge uppdelningen och vad varje token ger dig är vad en säkerhetsmedveten ingenjör förväntas veta.
Ett bibliotek med IT-intervjufrågor och detaljerade svar — från Junior till Senior.
Donera