Jeg har en ny SPA med en statsløs autentiseringsmodell som bruker JWT. Jeg blir ofte bedt om å henvise til OAuth for autentiseringsstrømmer som å be meg om å sende "Bearer tokens" for alle forespørsler i stedet for en enkel token header, men jeg tror at OAuth er mye mer kompleks enn en enkel JWT-basert autentisering. Hva er de viktigste forskjellene, bør jeg få JWT-autentiseringen til å oppføre seg som OAuth?
Jeg bruker også JWT som XSRF-TOKEN for å forhindre XSRF, men jeg blir bedt om å holde dem atskilt? Bør jeg holde dem atskilt? All hjelp her vil bli satt pris på og kan føre til et sett med retningslinjer for fellesskapet.
TL;DR Hvis du har veldig enkle scenarier, som en enkelt klientapplikasjon, et enkelt API, lønner det seg kanskje ikke å gå OAuth 2.0, på den annen side, mange forskjellige klienter (nettleserbasert, innfødt mobil, serverside osv.) Da kan det å holde seg til OAuth 2.0-regler gjøre det mer håndterbart enn å prøve å rulle ditt eget system.
Som nevnt i et annet svar, er JWT (Learn JSON Web Tokens) bare et tokenformat, det definerer en kompakt og selvstendig mekanisme for overføring av data mellom parter på en måte som kan verifiseres og stoles på fordi den er digitalt signert. I tillegg gjør kodingsreglene for en JWT disse tokenene svært enkle å bruke i forbindelse med HTTP.
Siden de er selvstendige (selve tokenet inneholder informasjon om et gitt emne), er de også et godt valg for å implementere tilstandsløse autentiseringsmekanismer (også kjent som Look mum, no sessions!). Når man går denne veien og det eneste en part må fremvise for å få tilgang til en beskyttet ressurs, er selve tokenet, kan det aktuelle tokenet kalles et bærertoken.
I praksis kan det du gjør allerede klassifiseres som basert på bærertokens. Vær imidlertid oppmerksom på at du ikke bruker bearer tokens som spesifisert i OAuth 2.0-relaterte spesifikasjoner (se RFC 6750). Det ville innebære å stole på HTTP-headeren Authorization
og bruke autentiseringsskjemaet Bearer
.
Når det gjelder bruk av JWT for å forhindre CSRF uten å vite nøyaktige detaljer, er det vanskelig å fastslå gyldigheten av denne praksisen, men for å være ærlig virker det ikke riktig og/eller verdt det. Følgende artikkel (Cookies vs Tokens: The Definitive Guide) kan være nyttig å lese om dette emnet, særlig avsnittet XSS and XSRF Protection.
Et siste råd, selv om du ikke trenger å gå full OAuth 2.0, vil jeg på det sterkeste anbefale å sende tilgangstokenet ditt i Authorization
-overskriften i stedet for å gå med tilpassede overskrifter. Hvis de virkelig er bærertokener, følg reglene i RFC 6750, hvis ikke, kan du alltid opprette et tilpasset autentiseringsskjema og fortsatt bruke den overskriften.
Autorisasjonshoder gjenkjennes og behandles spesielt av HTTP-proxyer og servere. Dermed reduserer bruken av slike overskrifter for å sende tilgangstokener til ressursservere sannsynligheten for lekkasje eller utilsiktet lagring av godkjente forespørsler generelt, og spesielt autorisasjonshoder.
(kilde: RFC 6819, avsnitt 5.4.1).
OAuth 2.0 definerer en protokoll, dvs. spesifiserer hvordan tokens overføres, JWT definerer et tokenformat.
OAuth 2.0 og "JWT-autentisering" har lignende utseende når det gjelder det (andre) trinnet der klienten presenterer tokenet til ressursserveren: tokenet sendes i en header.
Men "JWT-autentisering" er ikke en standard og spesifiserer ikke hvordan klienten får tokenet i utgangspunktet (det første trinnet). Det er der den opplevde kompleksiteten til OAuth kommer fra: den definerer også forskjellige måter klienten kan skaffe et tilgangstoken fra noe som kalles en autorisasjonsserver.
Så den virkelige forskjellen er at JWT bare er et tokenformat, OAuth 2.0 er en protokoll (som kan bruke en JWT som et tokenformat).
For det første må vi skille mellom JWT og OAuth. I utgangspunktet er JWT et tokenformat. OAuth er en autorisasjonsprotokoll som kan bruke JWT som et token. OAuth bruker lagring på serversiden og klientsiden. Hvis du vil gjøre ekte utlogging, må du bruke OAuth2. Autentisering med JWT-token kan faktisk ikke logge ut. Fordi du ikke har en autentiseringsserver som holder oversikt over tokens. Hvis du vil tilby et API til tredjepartsklienter, må du også bruke OAuth2. OAuth2 er veldig fleksibel. JWT-implementering er veldig enkelt og tar ikke lang tid å implementere. Hvis applikasjonen din trenger denne typen fleksibilitet, bør du velge OAuth2. Men hvis du ikke trenger dette bruksscenariet, er det bortkastet tid å implementere OAuth2.
XSRF-token sendes alltid til klienten i hvert svarhode. Det spiller ingen rolle om et CSRF-token sendes i et JWT-token eller ikke, fordi CSRF-tokenet er sikret med seg selv. Derfor er det unødvendig å sende CSRF-token i JWT.