Ik heb een nieuwe SPA met een stateless authenticatiemodel met JWT. Ik word vaak gevraagd om OAuth te verwijzen voor authenticatiestromen, zoals me vragen om ‘Bearer-tokens’ te sturen voor elk verzoek in plaats van een eenvoudige token-header, maar ik denk dat OAuth veel complexer is dan een eenvoudige op JWT gebaseerde authenticatie. Wat zijn de belangrijkste verschillen, moet ik ervoor zorgen dat de JWT-authenticatie zich als OAuth gedraagt?
Ik gebruik de JWT ook als mijn XSRF-TOKEN om XSRF te voorkomen, maar ik word gevraagd om ze gescheiden te houden? Moet ik ze gescheiden houden? Alle hulp hier wordt op prijs gesteld en kan leiden tot een reeks richtlijnen voor de gemeenschap.
Antwoord 1, autoriteit 100%
TL;DR
Als je heel eenvoudige scenario’s hebt, zoals een enkele clienttoepassing, een enkele API, dan loont het misschien niet om OAuth 2.0 te gebruiken, aan de andere kant, veel verschillende clients (browsergebaseerd, native mobiel, server-side, enz.) dan kan het vasthouden aan de OAuth 2.0-regels het beheersbaarder maken dan proberen je eigen systeem te gebruiken.
Zoals vermeld in een ander antwoord, is JWT (Learn JSON Web Tokens) gewoon een tokenformaat, het definieert een compact en op zichzelf staand mechanisme voor het verzenden van gegevens tussen partijen op een manier die kan worden geverifieerd en vertrouwd omdat het digitaal is ondertekend. Bovendien maken de coderingsregels van een JWT deze tokens ook zeer gemakkelijk te gebruiken binnen de context van HTTP.
Omdat ze op zichzelf staan (de eigenlijke token bevat informatie over een bepaald onderwerp), zijn ze ook een goede keuze voor het implementeren van staatloze authenticatiemechanismen (ook bekend als Kijk mama, geen sessies!). Wanneer deze route wordt bewandeld en het enige dat een partij moet overleggen om toegang te krijgen tot een beschermde bron het token zelf is, kan het betreffende token een dragertoken worden genoemd.
In de praktijk kan wat u doet al worden geclassificeerd als gebaseerd op tokens aan toonder. Houd er echter rekening mee dat u geen dragertokens gebruikt zoals gespecificeerd door de OAuth 2.0-gerelateerde specificaties (zie RFC 6750). Dat zou impliceren dat we moeten vertrouwen op de HTTP-header Authorizationen het authenticatieschema Bearergebruiken.
Met betrekking tot het gebruik van de JWT om CSRF te voorkomen zonder de exacte details te kennen, is het moeilijk om de geldigheid van die praktijk vast te stellen, maar om eerlijk te zijn lijkt het niet correct en/of de moeite waard. Het volgende artikel (Cookies vs Tokens: The Definitive Guide) kan wees een nuttige lectuur over dit onderwerp, met name de sectie XSS en XSRF-bescherming.
Nog een laatste advies, zelfs als u niet volledig OAuth 2.0 hoeft te gebruiken, raad ik u ten zeerste aan om uw toegangstoken door te geven in de Authorization-header in plaats van gebruik te maken van custom kopteksten. Als het echt tokens zijn, volg dan de regels van RFC 6750. Zo niet, dan kun je altijd een aangepast authenticatieschema maken en toch die header gebruiken.
Autorisatieheaders worden herkend en speciaal behandeld door HTTP-proxy’s en -servers. Het gebruik van dergelijke headers voor het verzenden van toegangstokens naar resourceservers vermindert dus de kans op lekkage of onbedoelde opslag van geverifieerde verzoeken in het algemeen, en in het bijzonder autorisatieheaders.
(bron: RFC 6819, sectie 5.4.1)
Antwoord 2, autoriteit 89%
OAuth 2.0 definieert een protocol, d.w.z. specificeert hoe tokens worden overgedragen, JWT definieert een tokenformaat.
OAuth 2.0 en “JWT-authenticatie” zien er hetzelfde uit als het gaat om de (2e) fase waarin de Client het token presenteert aan de Resource Server: het token wordt doorgegeven in een header.
Maar “JWT-authenticatie” is geen standaard en specificeert niet hoede klant het token in de eerste plaats verkrijgt (de eerste fase). Dat is waar de waargenomen complexiteit van OAuth vandaan komt: het definieert ook verschillende manieren waarop de klant een toegangstoken kan verkrijgenvan iets dat een autorisatieserver wordt genoemd.
Het echte verschil is dus dat JWT slechts een tokenformaat is, OAuth 2.0 is een protocol (dat mageen JWT als tokenformaat gebruiken).
Antwoord 3, autoriteit 40%
Ten eerste moeten we onderscheid maken tussen JWT en OAuth. Kortom, JWT is een token-indeling. OAuth is een autorisatieprotocol dat JWT als token kan gebruiken. OAuth maakt gebruik van server-side en client-side opslag. Als u echt wilt uitloggen, moet u OAuth2 gebruiken. Authenticatie met JWT-token kan eigenlijk niet uitloggen. Omdat je geen authenticatieserver hebt die tokens bijhoudt. Als u een API wilt aanbieden aan klanten van derden, moet u ook OAuth2 gebruiken. OAuth2 is erg flexibel. JWT-implementatie is heel eenvoudig en duurt niet lang om te implementeren. Als uw toepassing dit soort flexibiliteit nodig heeft, moet u OAuth2 gebruiken. Maar als u dit gebruiksscenario niet nodig heeft, is het implementeren van OAuth2 tijdverspilling.
XSRF-token wordt altijd in elke antwoordheader naar de client verzonden. Het maakt niet uit of een CSRF-token in een JWT-token wordt verzonden of niet, omdat het CSRF-token met zichzelf is beveiligd. Daarom is het niet nodig om een CSRF-token in JWT te verzenden.
Antwoord 4, autoriteit 23%
JWT (JSON Web Tokens)– Het is slechts een tokenformaat. JWT-tokens zijn JSON-gecodeerde datastructuren die informatie bevatten over de uitgever, onderwerp (claims), vervaltijd enz. Het is ondertekend voor fraudebestendigheid en authenticiteit en het kan worden gecodeerd om de tokeninformatie te beschermen met behulp van een symmetrische of asymmetrische benadering. JWT is eenvoudiger dan SAML 1.1/2.0 en wordt door alle apparaten ondersteund en is krachtiger dan SWT (Simple Web Token).
OAuth2– OAuth2 lost een probleem op waarbij de gebruiker toegang wil tot de gegevens met behulp van clientsoftware zoals browse-gebaseerde web-apps, native mobiele apps of desktop-apps. OAuth2 is alleen voor autorisatie, clientsoftware kan worden geautoriseerd om namens de eindgebruiker toegang te krijgen tot de bronnen met behulp van een toegangstoken.
OpenID Connect– OpenID Connect bouwt voort op OAuth2 en voegt authenticatie toe. OpenID Connect voegt een aantal beperkingen toe aan OAuth2, zoals UserInfo Endpoint, ID Token, detectie en dynamische registratie van OpenID Connect-providers en sessiebeheer. JWT is het verplichte formaat voor het token.
CSRF-beveiliging– U hoeft de CSRF-beveiliging niet te implementeren als u geen token opslaat in de browsercookie.
Antwoord 5, autoriteit 19%
Het lijkt erop dat iedereen die hier heeft geantwoord het betwiste punt van OAUTH heeft gemist
Van Wikipedia
OAuth is een open standaard voor toegangsdelegatie, die vaak wordt gebruikt als een manier voor internetgebruikers om websites of applicaties toegang te verlenen tot hun informatie op andere websites, maar zonder hen de wachtwoorden te geven.[1] Dit mechanisme wordt gebruikt door bedrijven zoals Google, Facebook, Microsoft en Twitter om gebruikers in staat te stellen informatie over hun accounts te delen met applicaties of websites van derden.
Het belangrijkste punt hier is access delegation. Waarom zou iemand OAUTH maken als er een op id/pwd gebaseerde authenticatie is, ondersteund door multifactor-authenticatie zoals OTP’s en verder kan worden beveiligd door JWT’s die worden gebruikt om de toegang tot de paden te beveiligen (zoals scopes in OAUTH) en de vervaldatum van de toegang
Het heeft geen zin om OAUTH te gebruiken als consumenten alleen toegang hebben tot hun bronnen (uw eindpunten) via hun vertrouwde websites (of apps) die door u weer worden gehost op uw eindpunten
U kunt alleen overgaan op OAUTH-authenticatie als u een OAUTH providerbent in de gevallen waarin de resource-eigenaren (gebruikers) toegang willen tot hun (uw) resources (eindpunten) via een externe client (externe app).En het is precies voor hetzelfde doel gemaakt, hoewel je het in het algemeen kunt misbruiken
Nog een belangrijke opmerking:
U gebruikt vrijelijk het woord authenticationvoor JWT en OAUTH, maar biedt geen van beide het authenticatiemechanisme. Ja, de ene is een tokenmechanisme en de andere is een protocol, maar eenmaal geverifieerd worden ze alleen gebruikt voor autorisatie (toegangsbeheer). U moet OAUTH ondersteunen met authenticatie van het OPENID-type of met uw eigen klantgegevens
Antwoord 6, autoriteit 3%
vind de belangrijkste verschillen tussen JWT & OAuth
-
OAuth 2.0 definieert een protocol & JWT definieert een tokenformaat.
-
OAuth kan JWT gebruiken als tokenformaat of toegangstoken, wat een dragertoken is.
-
OpenID connect gebruikt meestal JWT als tokenformaat.
Antwoord 7, autoriteit 2%
JWT is een open standaard die een compacte en op zichzelf staande manier definieert voor het veilig verzenden van informatie tussen partijen. Het is een authenticatieprotocol waarbij we toestaan dat gecodeerde claims (tokens) worden overgedragen tussen twee partijen (client en server) en het token wordt uitgegeven bij de identificatie van een client. Bij elk volgend verzoek sturen we het token.
Terwijl OAuth2 een autorisatieraamwerk is, waar het algemene procedures en instellingen heeft die door het raamwerk zijn gedefinieerd. JWT kan worden gebruikt als een mechanisme binnen OAuth2.
Je kunt hier meer over lezen
OAuth of JWT? Welke te gebruiken en waarom?
Antwoord 8
Jwt is een strikte set instructies voor het uitgeven en valideren van ondertekende toegangstokens. De tokens bevatten claims die door een app worden gebruikt om de toegang tot een gebruiker te beperken
OAuth2 daarentegen is geen protocol, het is een gedelegeerd autorisatiekader. denk een zeer gedetailleerde richtlijn, om gebruikers en applicaties specifieke machtigingen te laten autoriseren voor andere applicaties in zowel privé als openbare instellingen. OpenID Connect, dat bovenop OAUTH2 zit, geeft u authenticatie en autorisatie. Het beschrijft hoe meerdere verschillende rollen, gebruikers in uw systeem, server-side-apps zoals een API en clients zoals websites of native mobiele apps, zich met elkaar kunnen authenticeren
Opmerkingoauth2 kan werken met jwt , flexibele implementatie, uitbreidbaar naar verschillende applicaties