Žetona obstajata, da razrešita neposredno nasprotje: dostopni žeton mora biti poslan ob vsaki zahtevi (zato je zelo izpostavljen), obenem pa želiš seje, ki trajajo dolgo brez pogostih prijav. Obojega ne moreš varno imeti v enem žetonu — zato razdeliš nalogo.
Authorization ob vsakem klicu API. Ker se nenehno prenaša, je uhajanje verjetno; kratko trajanje pomeni, da ukraden skoraj takoj poteče.Login ──▶ access (15m) + refresh (30d)
Vsak klic API ──▶ pošlji access
Access potekel ──▶ pošlji refresh ──▶ nov access (+ zavrten refresh)
| En dolgoživ dostopni žeton | Access + refresh | |
|---|---|---|
| Izpostavljenost | Poslan ob vsaki zahtevi, živi dolgo → veliko okno kraje | Access kratkoživ; refresh redko poslan |
| Preklic | Težko (stateless JWT ni mogoče »odizdati«) | Prekliči žeton za osvežitev; access umre v minutah |
| UX | Pogosta ponovna prijava, če je kratek | Ostaneš prijavljen brez ponovnega vnosa poverilnic |
| Obseg škode ob uhajanju | Velik | Majhen (access hitro poteče) |
httpOnly, izven dosega XSS.To je standardna sodobna zasnova avtentikacije in spraševalci to vprašajo, da vidijo, ali razumeš zakaj, ne le kako. Ključni vpogled je kompromis: brezstanskost in kratka izpostavljenost (access) proti dolgim sejam in možnosti preklica (refresh). Napačna izvedba — dolgoživ dostopni žeton, brez rotacije, refresh shranjen v localStorage — spremeni en sam uhajan žeton v dolgotrajno kompromitacijo računa. Poimenovati delitev in to, kaj ti prinese vsak žeton, je tisto, kar naj bi vedel varnostno ozaveščen inženir.
Knjižnica IT vprašanj za razgovore s podrobnimi odgovori — od začetnika do izkušenega.
Doniraj