Man ir jauns SPA ar bezstāvokļa autentifikācijas modeli, izmantojot JWT. Mani bieži lūdz atsaukties uz OAuth autentifikācijas plūsmām, piemēram, lūdzot man sūtīt 'Bearer tokens' katram pieprasījumam, nevis vienkāršu token galveni, bet es domāju, ka OAuth ir daudz sarežģītāks nekā vienkārša JWT balstīta autentifikācija. Kādas ir galvenās atšķirības, vai man JWT autentifikācija jāuzvedas kā OAuth?
Es arī izmantoju JWT kā savu XSRF-TOKEN, lai novērstu XSRF, bet man tiek prasīts, lai tie būtu atsevišķi? Vai man tie būtu jānošķir? Būsim pateicīgi par jebkādu palīdzību, un, iespējams, tas varētu palīdzēt izveidot kopienai paredzētas vadlīnijas.
TL;DR Ja jums ir ļoti vienkārši scenāriji, piemēram, viena klienta lietojumprogramma, viens API, tad, iespējams, nav izdevīgi izmantot OAuth 2.0, no otras puses, ja ir daudz dažādu klientu (pārlūkprogramma, vietējie mobilie klienti, servera puse u. c.), tad OAuth 2.0 noteikumu ievērošana varētu būt vieglāk pārvaldāma nekā mēģinājumi izstrādāt savu sistēmu.
Kā minēts citā atbildē, JWT (Learn JSON Web Tokens) ir tikai žetonu formāts, tas definē kompaktu un pašpietiekamu mehānismu datu pārsūtīšanai starp pusēm tādā veidā, kas ir pārbaudāms un uzticams, jo ir digitāli parakstīts. Turklāt JWT kodēšanas noteikumi arī padara šos žetonus ļoti viegli lietojamus HTTP kontekstā.
Tā kā tie ir pašpietiekami (faktiskais žetons satur informāciju par konkrēto subjektu), tie ir arī laba izvēle bezstāvokļa autentifikācijas mehānismu īstenošanai (jeb Look mammu, nav sesiju!). Ja, izvēloties šo ceļu un vienīgais, kas pusei jāuzrāda, lai saņemtu piekļuvi aizsargātam resursam, ir pats žetons, attiecīgo žetonu var saukt par nesēja žetonu.
Praksē to, ko jūs darāt, jau var klasificēt kā tādu, kas balstīts uz uzrādītāja žetoniem. Tomēr ņemiet vērā, ka jūs neizmantojat nesēja žetonus, kā noteikts ar OAuth 2.0 saistītajās specifikācijās (sk. RFC 6750). Tas nozīmē, ka jāpaļaujas uz HTTP galveni Authorization
un jāizmanto Bearer
autentifikācijas shēma.
Attiecībā uz JWT izmantošanu, lai novērstu CSRF, nezinot precīzu informāciju, ir grūti pārliecināties par šādas prakses pamatotību, bet, godīgi sakot, tā nešķiet pareiza un/vai lietderīga. Par šo tēmu var noderīgi izlasīt šādu rakstu (Cookies vs Tokens: The Definitive Guide), jo īpaši sadaļu XSS un XSRF aizsardzība.
Pēdējais padoms - pat ja jums nav nepieciešams pilnībā izmantot OAuth 2.0, es rūpīgi ieteiktu nodot piekļuves žetonu Authorization
galvenē, nevis izmantot pielāgotas galvenes. Ja tie patiešām ir nesēja žetoni, ievērojiet RFC 6750 noteikumus, ja nē, vienmēr varat izveidot pielāgotu autentifikācijas shēmu un joprojām izmantot šo galveni.
Autorizācijas galvenes atpazīst un īpaši apstrādā HTTP starpnieki un serveri. Tādējādi šādu galvenu izmantošana piekļuves žetonu nosūtīšanai resursu serveriem samazina autentificētu pieprasījumu noplūdes vai neparedzētas saglabāšanas iespējamību kopumā un jo īpaši Authorization galvenes.
(avots: RFC 6819, 5.4.1. iedaļa).
OAuth 2.0 definē protokolu, t. i., nosaka, kā tiek pārsūtīti žetoni, savukārt JWT definē žetona formātu.
OAuth 2.0 un "JWT autentifikācijai" ir līdzīgs izskats, kad runa ir par (2.) posmu, kurā klients iesniedz žetonu resursu serverim: žetons tiek nodots galvenē.
Taču "JWT autentifikācija" nav standarts un nenosaka, kā Klients vispirms iegūst žetonu (1. posms). Tieši no tā rodas OAuth sarežģītības priekšstats: tajā ir definēti arī dažādi veidi, kā Klients var iegūt* piekļuves žetonu no kaut kā, ko sauc par autorizācijas serveri.
Tātad patiesā atšķirība ir tāda, ka JWT ir tikai žetona formāts, bet OAuth 2.0 ir protokols (kas var izmantot JWT kā žetona formātu).
Pirmkārt, mums ir jānošķir JWT un OAuth. Būtībā JWT ir žetona formāts. OAuth ir autorizācijas protokols, kas var izmantot JWT kā marķieri. OAuth izmanto servera un klienta puses krātuvi. Ja vēlaties veikt reālu izrakstīšanos, jāizmanto OAuth2. Autentifikācija ar JWT žetonu faktiski nav iespējama. Jo jums nav autentifikācijas servera, kas glabā žetonus. Ja vēlaties nodrošināt API trešo pušu klientiem, jums jāizmanto arī OAuth2. OAuth2 ir ļoti elastīgs. JWT ieviešana ir ļoti vienkārša un neprasa daudz laika. Ja jūsu lietojumprogrammai ir nepieciešama šāda veida elastība, jums jāizvēlas OAuth2. Bet, ja jums nav nepieciešams šāds lietojuma scenārijs, OAuth2 ieviešana ir laika izšķiešana.
XSRF žetons vienmēr tiek nosūtīts klientam katrā atbildes galvenē. Nav nozīmes, vai CSRF žetons tiek nosūtīts JWT žetonā vai nē, jo CSRF žetons ir nodrošināts ar sevi. Tāpēc CSRF token nosūtīšana JWT nav nepieciešama.