REST-API-Sicherheit: HMAC / Key-Hashing im Vergleich zu JWT

Ich habe gerade diesen Artikel gelesen , der ein paar Jahre alt ist, aber eine clevere Methode zum Sichern Ihrer REST-APIs beschreibt. Im Wesentlichen:

Jeder Client verfügt über ein eindeutiges öffentliches / privates Schlüsselpaar
Nur der Client und der Server kennen den privaten Schlüssel. Es wird nie über das Kabel gesendet
Bei jeder Anforderung verwendet der Client mehrere Eingaben (die gesamte Anforderung selbst, den aktuellen Zeitstempel und den privaten Schlüssel) und führt sie über eine HMAC-Funktion aus, um einen Hash der Anforderung zu erstellen
Der Client sendet dann die normale Anforderung (die den öffentlichen Schlüssel enthält) und den Hash an den Server
Der Server sucht nach dem privaten Schlüssel des Clients (basierend auf dem bereitgestellten öffentlichen Schlüssel) und führt eine Zeitstempelprüfung durch (die ich zugegebenermaßen nicht verstehe), um sicherzustellen, dass die Anforderung nicht Opfer einer Wiederholungsattacke ist
Wenn alles in Ordnung ist, verwendet der Server den privaten Schlüssel und dieselbe HMAC-Funktion, um einen eigenen Hash der Anforderung zu generieren
Der Server vergleicht dann beide Hashes (den vom Client gesendeten und den von ihm generierten). Wenn sie übereinstimmen, wird die Anforderung authentifiziert und kann fortgesetzt werden

Ich bin dann auf JWT gestoßen , was sich sehr ähnlich anhört. Im ersten Artikel wird JWT jedoch überhaupt nicht erwähnt, und daher frage ich mich, ob und wie JWT von der oben genannten Authentifizierungslösung abweicht.

— smeeb
quelle

Lol ... Ich wollte nur genau die gleiche Frage stellen und bin auf deine gestoßen. Eines der ersten Dinge, die ich über die zustandslose Authentifizierung erfuhr , stammte von der AWS: docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/… und implementierte so etwas wie dieses massimilianosciacco.com/… . Dann habe ich JWS / JWT gefunden und es ist irgendwie ähnlich. Nach meinem Verständnis ist JWT jedoch ein Standard, und die anderen oben beschriebenen Lösungen sind einige benutzerdefinierte Implementierungen (nicht standardisiert). Jemand korrigiert mich, wenn ich falsch liege.

— Nyxz

Gut zu wissen, dass ich nicht der einzige bin, der sich um solche Details kümmert! JWT fühlt sich sicherlich ähnlich und der Bonus ist, dass es standardisiert ist. Ich frage mich nur, wie es mit dieser benutzerdefinierten HMAC-Lösung (sicherheitstechnisch) funktioniert.

— Smeeb

Beginnen wir mit einer sehr einfachen Antwort.

JWT (wie im Kontext von OAuth und OpenID verwendet) erfordert keine gemeinsamen Geheimnisse zwischen Client und API. Es gibt 3 Komponenten und 2er-Paare, die jeweils ein Geheimnis teilen: Client <-> Identifikationsserver, Identifikationsserver <-> API.

Dadurch wird die meiste Komplexität von der API auf den Identifikationsserver verlagert. Die API muss lediglich überprüfen, ob das Token vom Identifikationsserver ausgestellt und nicht mit dem Temperament versehen wurde. Um zu überprüfen, ob die API die Gültigkeit der JWT-Signatur mit dem bekannten gemeinsamen Geheimnis zwischen Identifikationsserver und API überprüft. Das ist es!

Wie der Identifikationsserver die Benutzeridentität überprüft, kann sehr unterschiedlich sein (in vielen Fällen ist es das alte Paar aus Benutzername und Kennwort über eine TLS-Verbindung), hat jedoch keine Auswirkungen auf Ihre API.

Datenschutz und Sicherheit der Nachricht und des Tokens selbst bei Verwendung von JWT werden von TLS behandelt. JWT ist sich solcher Probleme nicht bewusst.

— Patrick
quelle