Ich habe eine neue SPA mit einem zustandslosen Authentifizierungsmodell mit JWT. Ich werde oft gebeten, OAuth für Authentifizierungsabläufe zu verwenden, z. B. indem man mich bittet, für jede Anfrage anstelle eines einfachen Token-Headers Token zu senden, aber ich denke, dass OAuth viel komplexer ist als eine einfache JWT-basierte Authentifizierung. Was sind die Hauptunterschiede, sollte ich die JWT-Authentifizierung so gestalten, dass sie sich wie OAuth verhält?
Ich verwende den JWT auch als meinen XSRF-TOKEN, um XSRF zu verhindern, aber ich werde gebeten, sie getrennt zu halten? Sollte ich sie getrennt halten? Wir sind für jede Hilfe dankbar, die zu einer Reihe von Leitlinien für die Gemeinschaft führen könnte.
TL;DR Wenn Sie sehr einfache Szenarien haben, z. B. eine einzige Client-Anwendung, eine einzige API, dann lohnt es sich möglicherweise nicht, OAuth 2.0 zu verwenden. Wenn Sie andererseits viele verschiedene Clients haben (browserbasiert, natives Mobiltelefon, serverseitig usw.), dann ist es möglicherweise einfacher, sich an die OAuth 2.0-Regeln zu halten, als zu versuchen, Ihr eigenes System zu entwickeln.
Wie bereits in einer anderen Antwort erwähnt, handelt es sich bei JWT (Learn JSON Web Tokens) lediglich um ein Token-Format, das einen kompakten und in sich geschlossenen Mechanismus für die Übermittlung von Daten zwischen Parteien auf eine Weise definiert, die verifiziert und vertrauenswürdig ist, da sie digital signiert ist. Darüber hinaus machen die Kodierungsregeln eines JWT diese Token auch sehr einfach im Kontext von HTTP zu verwenden.
Da sie in sich geschlossen sind (das eigentliche Token enthält Informationen über ein bestimmtes Subjekt), sind sie auch eine gute Wahl für die Implementierung zustandsloser Authentifizierungsmechanismen (aka Look mum, no sessions!). Wenn man diesen Weg geht und das Einzige, was eine Partei vorlegen muss, um Zugang zu einer geschützten Ressource zu erhalten, das Token selbst ist, kann das fragliche Token als Träger-Token bezeichnet werden.
In der Praxis kann das, was Sie tun, bereits als auf Inhaber-Tokens basierend eingestuft werden. Bedenken Sie jedoch, dass Sie keine Inhaber-Token verwenden, wie sie in den OAuth 2.0-Spezifikationen spezifiziert sind (siehe RFC 6750). Das würde bedeuten, dass Sie sich auf den Authorization
HTTP-Header verlassen und das Bearer
-Authentifizierungsschema verwenden.
Was die Verwendung von JWT zur Verhinderung von CSRF betrifft, so ist es ohne genaue Kenntnis der Details schwierig, die Gültigkeit dieser Praxis festzustellen, aber ehrlich gesagt scheint sie nicht korrekt und/oder sinnvoll zu sein. Der folgende Artikel (Cookies vs. Tokens: The Definitive Guide) kann eine nützliche Lektüre zu diesem Thema sein, insbesondere der Abschnitt XSS and XSRF Protection.
Noch ein letzter Ratschlag: Selbst wenn Sie OAuth 2.0 nicht in vollem Umfang nutzen müssen, würde ich Ihnen dringend empfehlen, Ihr Zugriffstoken im "Autorisierungs"-Header zu übergeben, anstatt benutzerdefinierte Header zu verwenden**. Wenn es sich wirklich um Inhaber-Tokens handelt, befolgen Sie die Regeln von RFC 6750, wenn nicht, können Sie immer ein benutzerdefiniertes Authentifizierungsschema erstellen und diesen Header trotzdem verwenden.
Autorisierungs-Header werden von HTTP-Proxys und -Servern erkannt und speziell behandelt. Die Verwendung solcher Header für die Übermittlung von Zugriffstoken an Ressourcenserver verringert daher die Wahrscheinlichkeit eines Lecks oder einer unbeabsichtigten Speicherung von authentifizierten Anfragen im Allgemeinen und insbesondere von Autorisierungs-Headern.
(Quelle: RFC 6819, Abschnitt 5.4.1)
OAuth 2.0 definiert ein Protokoll, d.h. legt fest, wie Token übertragen werden, JWT definiert ein Token-Format.
OAuth 2.0 und "JWT-Authentifizierung" haben ein ähnliches Erscheinungsbild, wenn es um die (2.) Stufe geht, in der der Client dem Ressourcenserver das Token präsentiert: Das Token wird in einem Header übergeben.
Aber "JWT-Authentifizierung" ist kein Standard und spezifiziert nicht, wie der Client das Token überhaupt erst erhält (die 1. Stufe). Daher rührt die wahrgenommene Komplexität von OAuth: Es definiert auch verschiedene Möglichkeiten, wie der Client ein Zugriffstoken von einem so genannten Autorisierungsserver erhalten kann.
Der eigentliche Unterschied besteht also darin, dass JWT nur ein Token-Format ist, während OAuth 2.0 ein Protokoll ist (das ein JWT als Token-Format verwenden kann).
Zunächst einmal müssen wir zwischen JWT und OAuth unterscheiden. Im Grunde genommen ist JWT ein Token-Format. OAuth ist ein Autorisierungsprotokoll, das JWT als Token verwenden kann. OAuth verwendet serverseitige und clientseitige Speicherung. Wenn Sie eine echte Abmeldung durchführen möchten, müssen Sie OAuth2 verwenden. Authentifizierung mit JWT-Token kann nicht wirklich abmelden. Denn Sie haben keinen Authentifizierungsserver, der die Token verwaltet. Wenn Sie 3rd-Party-Clients eine API zur Verfügung stellen wollen, müssen Sie auch OAuth2 verwenden. OAuth2 ist sehr flexibel. Die JWT-Implementierung ist sehr einfach und dauert nicht lange. Wenn Ihre Anwendung diese Art von Flexibilität benötigt, sollten Sie sich für OAuth2 entscheiden. Aber wenn Sie dieses Anwendungsszenario nicht benötigen, ist die Implementierung von OAuth2 reine Zeitverschwendung.
Das XSRF-Token wird immer in jedem Antwort-Header an den Client gesendet. Es spielt keine Rolle, ob ein CSRF-Token in einem JWT-Token gesendet wird oder nicht, da das CSRF-Token mit sich selbst gesichert ist. Daher ist das Senden eines CSRF-Tokens in einem JWT-Token unnötig.