it-swarm.com.de

Was sind die Hauptunterschiede zwischen der JWT- und der OAuth-Authentifizierung?

Ich habe ein neues SPA mit einem zustandslosen Authentifizierungsmodell, das JWT verwendet. Häufig werde ich gebeten, OAuth für Authentifizierungsabläufe zu verwenden, z. B. die Bitte, bei jeder Anforderung "Bearer-Token" anstelle eines einfachen Token-Headers zu senden. Ich denke jedoch, dass OAuth viel komplexer ist als eine einfache JWT-basierte Authentifizierung. Was sind die Hauptunterschiede, sollte ich die JWT-Authentifizierung wie OAuth verhalten lassen? 

Ich benutze das JWT auch als XSRF-TOKEN, um XSRF zu verhindern, aber ich werde gebeten, sie getrennt zu halten. Soll ich sie getrennt halten? Jede Hilfe hier wird geschätzt und kann zu einer Reihe von Richtlinien für die Community führen.

190
Tech Junkie

TL; DR Wenn Sie sehr einfache Szenarien haben, wie eine einzelne Clientanwendung, eine einzelne API, lohnt es sich möglicherweise nicht, OAuth 2.0 zu verwenden, andererseits viele verschiedene Clients (Browser) -Basis, nativen Mobilgeräten, Serverseiten usw.). Wenn Sie sich an die OAuth 2.0-Regeln halten, wird dies möglicherweise einfacher, als wenn Sie versuchen, Ihr eigenes System zu rollen.


Wie bereits in einer anderen Antwort erwähnt, ist JWT ( Learn JSON Web Tokens ) nur ein Token-Format. Es definiert einen kompakten und in sich geschlossenen Mechanismus für die Übertragung von Daten zwischen Parteien auf eine Art und Weise, die aufgrund der digitalen Verifizierung überprüft und als vertrauenswürdig eingestuft werden kann unterzeichnet. Darüber hinaus machen die Codierungsregeln einer JWT die Verwendung dieser Token im Kontext von HTTP sehr einfach.

Da sie in sich geschlossen sind (das eigentliche Token enthält Informationen zu einem bestimmten Thema), sind sie auch eine gute Wahl für die Implementierung von statuslosen Authentifizierungsmechanismen (aka Look mum, keine Sitzungen!). Wenn Sie auf diese Route gehen und nur eine Partei präsentieren muss, um Zugriff auf eine geschützte Ressource zu erhalten, ist das Token selbst. Das betreffende Token kann als Trägertoken bezeichnet werden.

In der Praxis kann das, was Sie tun, bereits als Trägerzeichen klassifiziert werden. Bedenken Sie jedoch, dass Sie keine Trägertoken verwenden, wie in den Spezifikationen für OAuth 2.0 angegeben (siehe RFC 6750 ). Dies würde bedeuten, sich auf den Authorization-HTTP-Header zu verlassen und das Bearer-Authentifizierungsschema zu verwenden.

In Bezug auf die Verwendung der JWT zur Vermeidung von CSRF, ohne genaue Angaben zu kennen, ist es schwierig, die Gültigkeit dieser Praxis zu ermitteln, aber um ehrlich zu sein, scheint dies nicht richtig und/oder lohnenswert zu sein. Der folgende Artikel ( Cookies vs Tokens: The Definitive Guide ) kann zu diesem Thema nützlich sein, insbesondere den Abschnitt XSS und XSRF Protection.

Ein letzter Ratschlag, auch wenn Sie OAuth 2.0 nicht vollständig ausführen müssen, würde ich würde dringend empfehlen, Ihr Zugriffstoken innerhalb der Authorization-Kopfzeile zu übergeben, anstatt benutzerdefinierte Kopfzeilen zu verwenden. Wenn es sich wirklich um Trägertoken handelt, folgen Sie den Regeln von RFC 6750. Wenn nicht, können Sie immer ein benutzerdefiniertes Authentifizierungsschema erstellen und diesen Header dennoch verwenden.

Berechtigungsheader werden von HTTP-Proxys und -Servern erkannt und speziell behandelt. Somit verringert die Verwendung solcher Header zum Senden von Zugriffstoken an Ressourcenserver die Wahrscheinlichkeit, dass authentifizierte Anforderungen allgemein und insbesondere Berechtigungsheader versickern oder unbeabsichtigt gespeichert werden.

(Quelle: RFC 6819, Abschnitt 5.4.1 )

190
João Angelo

OAuth 2.0 definiert ein Protokoll, d. H. Spezifiziert, wie Token übertragen werden, JWT definiert ein Tokenformat.

OAuth 2.0 und "JWT-Authentifizierung" sehen in der (zweiten) Phase, in der der Client das Token dem Ressourcenserver präsentiert, ähnlich aus: Das Token wird in einem Header übergeben.

"JWT-Authentifizierung" ist jedoch kein Standard und gibt nicht an , wie der Client das Token an erster Stelle erhält (1. Stufe). Daher kommt die wahrgenommene Komplexität von OAuth: Sie definiert auch verschiedene Arten, auf die der Kunde eine erhalten kann Zugriffstoken von etwas, das als Authorization Server bezeichnet wird.

Der wirkliche Unterschied ist also, dass JWT nur ein Token-Format ist. OAuth 2.0 ist ein Protokoll (das ein verwenden kann JWT als Token-Format).

201
Hans Z.

Erstens müssen wir JWT und OAuth unterscheiden. Grundsätzlich ist JWT ein Token-Format. OAuth ist ein Berechtigungsprotokoll, das JWT als Token verwenden kann. OAuth verwendet serverseitigen und clientseitigen Speicher. Wenn Sie eine echte Abmeldung durchführen möchten, müssen Sie OAuth2 verwenden. Die Authentifizierung mit JWT-Token kann sich eigentlich nicht abmelden. Weil Sie keinen Authentifizierungsserver haben, der Token verfolgt. Wenn Sie eine API für Drittanbieter-Clients bereitstellen möchten, müssen Sie auch OAuth2 verwenden. OAuth2 ist sehr flexibel. Die Implementierung von JWT ist sehr einfach und dauert nicht lange. Wenn Ihre Anwendung diese Flexibilität erfordert, sollten Sie sich für OAuth2 entscheiden. Wenn Sie dieses Anwendungsfallszenario jedoch nicht benötigen, ist die Implementierung von OAuth2 eine Zeitverschwendung.

Das XSRF-Token wird in jedem Antwortheader immer an den Client gesendet. Es spielt keine Rolle, ob ein CSRF-Token in einem JWT-Token gesendet wird oder nicht, da das CSRF-Token bei sich selbst gesichert ist. Daher ist das Senden eines CSRF-Token in JWT nicht erforderlich.

70

JWT (JSON-Web-Token) - Dies ist nur ein Token-Format. JWT-Token sind JSON-codierte Datenstrukturen, die Informationen über Aussteller, Betreff (Ansprüche), Ablaufzeit usw. enthalten. Sie sind für Manipulationssicherheit und Authentizität signiert und können zum Schutz der Tokeninformationen mithilfe eines symmetrischen oder asymmetrischen Ansatzes verschlüsselt werden. JWT ist einfacher als SAML 1.1/2.0 und wird von allen Geräten unterstützt. Es ist leistungsfähiger als SWT (Simple Web Token).

OAuth2 - OAuth2 löst ein Problem, bei dem der Benutzer mithilfe von Client-Software, wie beispielsweise browserbasierte Web-Apps, native mobile Apps oder Desktop-Apps, auf die Daten zugreifen möchte. OAuth2 dient nur zur Autorisierung. Client-Software kann für den Endbenutzer über das Zugriffstoken auf die Ressourcen zugreifen.

OpenID Connect - OpenID Connect baut auf OAuth2 auf und fügt Authentifizierung hinzu. OpenID Connect fügt OAuth2 einige Einschränkungen hinzu, z. B. UserInfo Endpoint, ID-Token, Erkennung und dynamische Registrierung von OpenID Connect-Providern sowie Sitzungsmanagement. JWT ist das obligatorische Format für das Token.

CSRF-Schutz - Sie müssen den CSRF-Schutz nicht implementieren, wenn Sie kein Token im Cookie des Browsers speichern.

Weitere Informationen finden Sie hier http://proficientblog.com/microservices-security/

35
ManishSingh

Es sieht so aus, als hätten alle, die hier geantwortet haben, den Streitpunkt von OAUTH verpasst

Aus Wikipedia

OAuth ist ein offener Standard für die Zugriffsberechtigung, der im Allgemeinen als Möglichkeit für Internetbenutzer verwendet wird, Websites oder Anwendungen Zugriff auf ihre Informationen auf anderen Websites zu gewähren, ohne ihnen jedoch die Passwörter zu geben. [1] Dieser Mechanismus wird von Unternehmen wie Google, Facebook, Microsoft und Twitter verwendet, um den Nutzern zu ermöglichen, Informationen über ihre Konten mit Anwendungen oder Websites Dritter zu teilen.

Der Schlüsselpunkt hier ist access delegation. Warum sollte jemand OAUTH erstellen, wenn es eine auf ID/Pwd basierende Authentifizierung gibt, die durch mehrstufige Authentifizierung wie OTPs unterstützt wird, und darüber hinaus durch JWTs gesichert werden kann, mit denen der Zugriff auf die Pfade (z. B. Bereiche in OAUTH) gesichert und das Ablaufdatum des OAUTH festgelegt wird Zugriff

Es gibt keinen Sinn, OAUTH zu verwenden, wenn Verbraucher auf ihre Ressourcen (Ihre Endpunkte) nur über ihre vertrauenswürdigen Websites (oder Apps) zugreifen, die wiederum auf Ihren Endpunkten gehostet werden

Sie können nur die OAUTH-Authentifizierung durchführen wenn Sie OAUTH provider sind, wenn die Ressourceneigentümer (Benutzer) über einen Drittanbieter-Client (externe App) auf ihre (Ihre) Ressourcen (Endpunkte) zugreifen möchten. Und es ist genau für den gleichen Zweck erstellt, obwohl Sie es generell missbrauchen können

Ein weiterer wichtiger Hinweis:
Sie verwenden das Wort authentication für JWT und OAUTH frei, stellen jedoch keinen Authentifizierungsmechanismus bereit. Ja, einer ist ein Tokenmechanismus und der andere ist ein Protokoll, aber sobald er authentifiziert ist, werden sie nur für die Autorisierung (Zugriffsverwaltung) verwendet. Sie müssen OAUTH entweder mit der Authentifizierung vom Typ OPENID oder Ihren eigenen Client-Anmeldeinformationen unterstützen

29
user3151330

JWT ist ein Authentifizierungsprotokoll, bei dem verschlüsselte Ansprüche (Token) zwischen zwei Parteien (Client und Server) übertragen werden. Das Token wird bei der Identifizierung eines Clients ausgegeben. Bei jeder nachfolgenden Anfrage senden wir das Token.

OAuth2 ist ein Genehmigungsrahmen, in dem allgemeine Verfahren und Einstellungen festgelegt sind, die durch den Rahmen definiert werden. JWT kann als Mechanismus in OAuth2 verwendet werden.

Mehr dazu lesen Sie hier

OAuth oder JWT? Welches ist zu verwenden und warum?

5
Samuel J Mathew

finden Sie die Hauptunterschiede zwischen JWT & OAuth

  1. OAuth 2.0 definiert ein Protokoll und JWT definiert ein Token-Format.

  2. OAuth kann entweder JWT als Token-Format oder Access-Token als Bearer-Token verwenden.

  3. OpenID Connect verwendet meistens JWT als Token-Format.

0

Jwt enthält strikte Anweisungen für die Ausgabe und Validierung signierter Zugriffstoken. Die Token enthalten Ansprüche, die von einer App verwendet werden, um den Zugriff auf einen Benutzer zu beschränken

OAuth2 ist dagegen kein Protokoll, sondern ein delegiertes Berechtigungssystem. Eine sehr ausführliche Richtlinie, in der Benutzer und Anwendungen bestimmte Berechtigungen für andere Anwendungen sowohl im privaten als auch im öffentlichen Bereich autorisieren dürfen. OpenID Connect, das sich auf OAUTH2 befindet, gibt Authentication und Authorization.it an, wie mehrere verschiedene Rollen, Benutzer in Ihrem System, serverseitige Apps wie ein API und Clients wie Websites oder native mobile Apps sich bei jedem anderen authentifizieren können

Hinweis oauth2 kann mit jwt arbeiten, flexible Implementierung, erweiterbar auf verschiedene Anwendungen

0
naila naseem