web-dev-qa-db-de.com

RESTful Authentifizierung

Was bedeutet RESTful-Authentifizierung und wie funktioniert sie? Ich kann keine gute Übersicht bei Google finden. Ich verstehe nur, dass Sie den Sitzungsschlüssel (remeberal) in der URL übergeben. Dies könnte jedoch furchtbar falsch sein.

693
Jim Keener

Wie mit der Authentifizierung in einer RESTful-Client-Server-Architektur umgegangen wird, ist umstritten.

Häufig kann dies in der SOA über HTTP-Welt erreicht werden durch:

  • HTTP-Basisauthentifizierung über HTTPS;
  • Cookies und Sitzungsmanagement;
  • Token in HTTP-Headern (z. B. OAuth 2.0 + JWT);
  • Abfrageauthentifizierung mit zusätzlichen Signaturparametern.

Sie müssen diese Techniken anpassen oder sogar besser mischen, um sie optimal an Ihre Softwarearchitektur anzupassen.

Jedes Authentifizierungsschema verfügt über eigene PROs und CONs, abhängig vom Zweck Ihrer Sicherheitsrichtlinie und Ihrer Softwarearchitektur.

HTTP-Basisauthentifizierung über HTTPS

Diese erste Lösung, die auf dem Standard-HTTPS-Protokoll basiert, wird von den meisten Web-Services verwendet.

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Es ist einfach zu implementieren, standardmäßig in allen Browsern verfügbar, weist jedoch einige bekannte Nachteile auf, wie z. B. das schreckliche Authentifizierungsfenster, das im Browser angezeigt wird (es gibt hier keine LogOut-ähnliche Funktion), einige serverseitige zusätzliche CPU-Auslastung. und die Tatsache, dass Benutzername und Kennwort (über HTTPS) an den Server übertragen werden (es sollte sicherer sein, das Kennwort nur auf der Clientseite während der Tastatureingabe zu belassen und als sicherer Hash auf dem Server zu speichern). .

Wir können Digest Authentication verwenden, aber es erfordert auch HTTPS, da es anfällig für MiM oder Replay Angriffe ist und spezifisch für HTTP ist.

Sitzung über Cookies

Um ehrlich zu sein, ist eine auf dem Server verwaltete Sitzung nicht wirklich staatenlos.

Eine Möglichkeit könnte darin bestehen, alle Daten innerhalb des Cookie-Inhalts zu pflegen. Das Cookie wird auf der Serverseite behandelt (der Client versucht sogar nicht, diese Cookie-Daten zu interpretieren; er gibt ihn bei jeder nachfolgenden Anfrage zurück an den Server). Bei diesen Cookie-Daten handelt es sich jedoch um Daten zum Anwendungsstatus. Daher sollte der Client sie und nicht den Server in einer reinen Staatenlosen Welt verwalten.

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

Die Cookie-Technik selbst ist HTTP-verknüpft, daher ist sie nicht wirklich RESTful, was protokollunabhängig sein sollte, IMHO. Es ist anfällig für MiM oder Replay Angriffe.

Über Token vergeben (OAuth2)

Alternativ können Sie ein Token in die HTTP-Header einfügen, damit die Anforderung authentifiziert wird. Dies ist beispielsweise das, was OAuth 2.0 tut. Siehe RFC 6749 :

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

Kurz gesagt, dies ist einem Cookie sehr ähnlich und leidet an den gleichen Problemen: Nicht zustandslos, auf HTTP-Übertragungsdetails angewiesen, und eine Menge Sicherheitslücken - einschließlich MiM und Replay - ist dies also wird nur über HTTPS verwendet. Normalerweise wird ein JWT als Token verwendet.

Query Authentication

Bei der Abfrageauthentifizierung wird jede RESTful-Anforderung über einige zusätzliche Parameter in der URI signiert. Siehe diesen Referenzartikel

Es wurde in diesem Artikel als solches definiert:

Alle REST Abfragen müssen durch Signieren der Abfrageparameter .__ authentifiziert werden. alphabetisch in Kleinbuchstaben sortiert, wobei der private Berechtigungsnachweis verwendet wird als unterzeichnendes Zeichen. Die Signatur sollte vor der URL-Kodierung von .__ erfolgen. Abfragezeichenfolge.

Diese Technik ist möglicherweise mit einer stateless-Architektur besser kompatibel und kann auch mit einer Light-Session-Verwaltung (Verwendung von In-Memory-Sitzungen anstelle von DB-Persistenz) implementiert werden.

Hier ein Beispiel eines generischen URI-Beispiels aus dem obigen Link:

GET /object?apiKey=Qwerty2010

sollte als solche übermittelt werden:

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

Die signierte Zeichenfolge ist /object?apikey=Qwerty2010&timestamp=1261496500 und die Signatur ist der SHA256-Hash dieser Zeichenfolge unter Verwendung der privaten Komponente des API-Schlüssels.

Das serverseitige Zwischenspeichern von Daten kann jederzeit verfügbar sein. In unserem Framework speichern wir die Antworten beispielsweise auf SQL-Ebene, nicht auf URI-Ebene. Durch das Hinzufügen dieses zusätzlichen Parameters wird der Cache-Mechanismus also nicht beschädigt.

Weitere Informationen zur RESTful-Authentifizierung in unserem Client-Server-ORM/SOA/MVC-Framework (basierend auf JSON und REST) ​​finden Sie unter diesen Artikel . Da wir die Kommunikation nicht nur über HTTP/1.1, sondern auch Named Pipes oder GDI Nachrichten (lokal) zulassen, haben wir versucht, ein wirklich RESTful-Authentifizierungsmuster zu implementieren und nicht auf die HTTP-Spezifität (wie Header oder Cookies) angewiesen. .

Later Hinweis: Das Hinzufügen einer Signatur in den URI kann als schlechte Praxis angesehen werden (da sie beispielsweise in den HTTP-Serverprotokollen angezeigt wird), muss sie gemildert werden, z. durch eine richtige TTL, um Wiederholungen zu vermeiden. Wenn Ihre http-Protokolle jedoch gefährdet sind, werden Sie sicherlich größere Sicherheitsprobleme haben.

In der Praxis kann die bevorstehende MAC-Tokens-Authentifizierung für OAuth 2.0 eine erhebliche Verbesserung gegenüber dem aktuellen Schema "Zugegeben durch Token" darstellen. Dies ist jedoch immer noch in Arbeit und an die HTTP-Übertragung gebunden.Fazit.

Es sollte der Schluss gezogen werden, dass REST nicht nur HTTP-basiert ist, auch wenn es in der Praxis auch meistens über HTTP implementiert wird. REST kann andere Kommunikationsschichten verwenden. Eine RESTful-Authentifizierung ist also nicht nur ein Synonym für HTTP-Authentifizierung, wie auch immer Google antwortet. Es sollte sogar überhaupt nicht den HTTP-Mechanismus verwenden, sondern sollte von der Kommunikationsschicht abstrahiert werden. Wenn Sie die HTTP-Kommunikation verwenden, gibt es dank der _ (Initiative Let's Encrypt)} keinen Grund, kein richtiges HTTPS zu verwenden, das zusätzlich zu einem Authentifizierungsschema erforderlich ist.

It's worth concluding that REST is not only HTTP-based, even if, in practice, it's also mostly implemented over HTTP. REST can use other communication layers. So a RESTful authentication is not just a synonym of HTTP authentication, whatever Google answers. It should even not use the HTTP mechanism at all but shall be abstracted from the communication layer. And if you use HTTP communication, thanks to the Let's Encrypt initiative there is no reason not to use proper HTTPS, which is required in addition to any authentication scheme.

542
Arnaud Bouchez

Ich bezweifle, dass die Leute, die begeistert "HTTP Authentication" schreien, jemals versucht haben, eine browserbasierte Anwendung (anstelle eines Machine-to-Machine-Web-Service) mit REST zu erstellen (keine Beleidigung beabsichtigt - ich glaube einfach nicht, dass sie dies jemals tun die Komplikationen konfrontiert).

Bei der Verwendung der HTTP-Authentifizierung in RESTful-Diensten, die HTML-Seiten erstellen, die in einem Browser angezeigt werden sollen, gab es folgende Probleme:

  • benutzer erhalten normalerweise eine hässliche, vom Browser erstellte Anmeldebox, die sehr benutzerunfreundlich ist. Sie können keine Kennwortabfrage, Hilfefelder usw. hinzufügen.
  • abmelden oder Anmelden unter einem anderen Namen ist ein Problem. Browser senden weiterhin Authentifizierungsinformationen an die Website, bis Sie das Fenster schließen
  • timeouts sind schwierig

Ein sehr aufschlussreicher Artikel, der diese Punkte Punkt für Punkt aufgreift, ist here . Dies führt jedoch zu einem lot von browserspezifischen Javascript-Hackern, Problemumgehungen für Workarounds und so weiter. Daher ist es auch nicht vorwärtskompatibel und erfordert daher eine ständige Wartung, wenn neue Browser veröffentlicht werden. Ich denke nicht über das klare und klare Design nach, und ich habe das Gefühl, dass es zusätzliche Arbeit und Kopfschmerzen gibt, nur damit ich meinen Freunden das REST-Abzeichen begeistert zeigen kann.

Ich glaube, dass Cookies die Lösung sind. Aber warten Sie, Cookies sind böse, nicht wahr? Nein, das ist nicht so, wie oft Cookies verwendet werden, ist böse. Ein Cookie selbst ist nur eine Information auf Client-Seite, genau wie die HTTP-Authentifizierungsinformationen, die der Browser beim Browsen nachverfolgen würde. Diese clientseitigen Informationen werden bei jeder Anforderung an den Server gesendet, genau wie die HTTP-Authentifizierungsinformationen. Konzeptionell besteht der einzige Unterschied darin, dass der content dieses Teils des clientseitigen Status vom server als Teil seiner Antwort bestimmt werden kann.

Wenn Sie Sitzungen zu einer RESTful-Ressource mit den folgenden Regeln machen:

  • Ein session ordnet einer Benutzerkennung einen Schlüssel zu (und möglicherweise einen Zeitstempel der letzten Aktion für Zeitüberschreitungen).
  • Wenn ein session vorhanden ist, bedeutet dies, dass der Schlüssel gültig ist.
  • Login bedeutet POST zu/Sitzungen, ein neuer Schlüssel wird als Cookie gesetzt
  • Abmelden bedeutet DELETEing/sessions/{key} (mit dem überladenen POST, denken Sie daran, wir sind ein Browser und HTML 5 ist noch ein weiter Weg)
  • Die Authentifizierung erfolgt durch Senden des Schlüssels als Cookie bei jeder Anforderung und Überprüfen, ob die Sitzung existiert und gültig ist

Der einzige Unterschied zur HTTP-Authentifizierung besteht jetzt darin, dass der Authentifizierungsschlüssel vom Server generiert und an den Client gesendet wird, der ihn immer wieder zurücksendet, anstatt dass er vom Client aus den eingegebenen Anmeldeinformationen berechnet wird.

converter42 fügt hinzu, dass es bei der Verwendung von https (was wir tun sollten) wichtig ist, dass das Cookie für das Cookie gesetzt ist, damit die Authentifizierungsinformationen niemals über eine nicht sichere Verbindung gesendet werden. Toller Punkt, hatte es selbst nicht gesehen.

Ich denke, dass dies eine ausreichende Lösung ist, die gut funktioniert, aber ich muss zugeben, dass ich nicht als Sicherheitsexperte genug bin, um potenzielle Lücken in diesem System zu identifizieren. Ich weiß nur, dass Hunderte von nicht-REST-fähigen Webanwendungen im Wesentlichen das gleiche verwenden Anmeldeprotokoll ($ _SESSION in PHP, HttpSession in Java EE usw.). Der Inhalt des Cookie-Headers wird einfach verwendet, um eine serverseitige Ressource zu adressieren, genau wie eine Accept-Sprache für den Zugriff auf Übersetzungsressourcen usw. verwendet werden kann. Ich habe das Gefühl, dass es das gleiche ist, aber vielleicht nicht? Was denkt ihr Leute?

410
skrebbel

Genug ist zu diesem Thema schon gesagt von guten Leuten hier. Aber hier sind meine 2 Cent.

Es gibt 2 Arten der Interaktion:

  1. mensch-zu-Maschine (HTM)
  2. maschine-zu-Maschine (MTM)

Die Maschine ist der gemeinsame Nenner, ausgedrückt als REST APIs, und die Akteure/Kunden sind entweder die Menschen oder die Maschinen.

In einer wirklich REST-konformen Architektur impliziert das Konzept der Zustandslosigkeit, dass alle relevanten Anwendungszustände (dh die clientseitigen Zustände) mit jeder einzelnen Anforderung bereitgestellt werden müssen. Mit relevant ist gemeint, dass alles, was von der API REST benötigt wird, um die Anforderung zu verarbeiten und eine angemessene Antwort zu liefern.

Wenn wir dies im Kontext von Mensch-Maschine-Anwendungen betrachten, die "browserbasiert" sind, wie Skrebbel oben ausgeführt hat, bedeutet dies, dass die (Web-) Anwendung, die im Browser ausgeführt wird, ihren Status und relevante Informationen bei jeder Anforderung senden muss Es werden APIs für das Back-End REST erstellt.

Beachten Sie Folgendes: Sie verfügen über ein auf einer Daten-/Informationsplattform verfügbares Asset mit REST - APIs. Möglicherweise verfügen Sie über eine Self-Service-BI-Plattform, die alle Datenwürfel verwaltet. Sie möchten jedoch, dass Ihre (menschlichen) Kunden über (1) Web-App, (2) mobile App und (3) eine Drittanbieteranwendung auf diese zugreifen. Am Ende führt eine gleichmäßige Kette von MTMs zu HTM - richtig. So bleiben menschliche Nutzer an der Spitze der Informationskette.

In den ersten beiden Fällen handelt es sich um einen Fall der Interaktion zwischen Mensch und Maschine, bei dem die Informationen tatsächlich von einem menschlichen Benutzer verbraucht werden. Im letzten Fall haben Sie ein Computerprogramm, das die APIs REST verwendet.

Das Konzept der Authentifizierung gilt allgemein. Wie gestalten Sie dies, damit auf Ihre REST - APIs einheitlich und sicher zugegriffen werden kann? So wie ich das sehe, gibt es zwei Möglichkeiten:

Weg-1:

  1. Zunächst gibt es keine Anmeldung. Jede Anfrage führt die Anmeldung durch
  2. Der Client sendet seine identifizierenden Parameter + die anforderungsspezifischen Parameter mit jeder Anforderung
  3. Die API REST nimmt sie entgegen, dreht sich um, pingt den Benutzerspeicher (was auch immer das ist) und bestätigt die Authentifizierung
  4. Wenn die Authentifizierung hergestellt ist, wird die Anforderung bearbeitet. Andernfalls wird mit dem entsprechenden HTTP-Statuscode verweigert
  5. Wiederholen Sie die obigen Schritte für jede Anforderung für alle REST - APIs in Ihrem Katalog

Weg-2:

  1. Der Client beginnt mit einer Authentifizierungsanfrage
  2. Eine Login-API REST verarbeitet alle derartigen Anforderungen
  3. Es werden Authentifizierungsparameter (API-Schlüssel, UID/PWD oder was auch immer Sie wählen) verwendet und die Authentifizierung wird anhand des Benutzerspeichers (LDAP, AD oder MySQL DB usw.) überprüft.
  4. Wenn überprüft, wird ein Authentifizierungstoken erstellt und an den Client/Anrufer zurückgegeben
  5. Der Anrufer sendet dann dieses Authentifizierungstoken + anforderungsspezifische Parameter mit jeder nachfolgenden Anforderung an andere REST Geschäfts-APIs, bis er abgemeldet wird oder bis der Vertrag abläuft

In Methode 2 müssen die APIs REST eindeutig die Möglichkeit haben, das Token als gültig zu erkennen und ihm zu vertrauen. Die Anmelde-API hat die Authentifizierungsüberprüfung durchgeführt, und daher müssen andere REST - APIs in Ihrem Katalog diesem "Valet Key" vertrauen.

Dies bedeutet natürlich, dass der Authentifizierungsschlüssel/-token gespeichert und von den REST - APIs gemeinsam genutzt werden muss. Dieses gemeinsam genutzte, vertrauenswürdige Token-Repository kann lokal oder föderiert sein, sodass REST - APIs anderer Organisationen sich gegenseitig vertrauen können.

Aber ich schweife ab.

Der Punkt ist, dass ein "Status" (über den authentifizierten Status des Clients) beibehalten und gemeinsam genutzt werden muss, damit alle REST - APIs einen Vertrauenskreis bilden können. Wenn wir dies nicht tun, müssen wir akzeptieren, dass für alle eingehenden Anfragen eine Authentifizierung durchgeführt werden muss.

Die Authentifizierung ist ein ressourcenintensiver Prozess. Stellen Sie sich vor, Sie führen für jede eingehende Anforderung SQL-Abfragen für Ihren Benutzerspeicher aus, um zu prüfen, ob die UID/PWD-Übereinstimmung vorliegt. Oder zum Verschlüsseln und Durchführen von Hash-Übereinstimmungen (AWS-Stil). Und architektonisch muss jede REST - API dies vermutlich mithilfe eines gemeinsamen Back-End-Anmeldedienstes ausführen. Denn wenn Sie dies nicht tun, verunreinigen Sie den Auth-Code überall. Ein großes Durcheinander.

Also mehr die Schichten, mehr Latenz.

Nehmen Sie nun Way-1 und bewerben Sie sich bei HTM. Interessiert es Ihren (menschlichen) Benutzer wirklich, ob Sie bei jeder Anfrage uid/pwd/hash oder was auch immer senden müssen? Nein, solange Sie sie nicht stören, indem Sie jede Sekunde die Authentifizierungs-/Anmeldeseite aufrufen. Viel Glück, wenn Sie Kunden haben. Sie müssen also die Anmeldeinformationen auf der Clientseite im Browser direkt am Anfang speichern und bei jeder Anforderung senden. Für den (menschlichen) Benutzer hat sie sich bereits angemeldet und eine "Sitzung" ist verfügbar. In Wirklichkeit wird sie jedoch bei jeder Anfrage authentifiziert.

Gleiches gilt für Way-2. Ihr (menschlicher) Benutzer wird es niemals bemerken. Es wurde also kein Schaden angerichtet.

Was ist, wenn wir Way-1 auf MTM anwenden? In diesem Fall, da es sich um eine Maschine handelt, können wir diesem Typen die Hölle langweilen, indem wir ihn bitten, bei jeder Anfrage Authentifizierungsinformationen einzureichen. Niemanden interessierts! Wenn Sie Way-2 auf MTM ausführen, wird keine besondere Reaktion ausgelöst. Es ist eine verdammte Maschine. Es könnte weniger kümmern!

Die Frage ist also, was Ihrem Bedarf entspricht. Staatenlosigkeit hat einen Preis zu zahlen. Zahlen Sie den Preis und fahren Sie fort. Wenn Sie ein Purist sein wollen, dann zahlen Sie auch den Preis dafür und fahren Sie fort.

Am Ende spielen Philosophien keine Rolle. Was wirklich zählt, ist die Entdeckung, Präsentation und das Konsumerlebnis von Informationen. Wenn die Leute Ihre APIs lieben, haben Sie Ihren Job gemacht.

135
Kingz

Hier ist eine wirklich und vollständig RESTful-Authentifizierungslösung:

  1. Erstellen Sie ein öffentliches/privates Schlüsselpaar auf dem Authentifizierungsserver.
  2. Verteilen Sie den öffentlichen Schlüssel an alle Server.
  3. Wenn sich ein Client authentifiziert:

    3.1. Geben Sie ein Token aus, das Folgendes enthält:

    • Ablaufzeit
    • benutzername (optional)
    • benutzer IP (optional)
    • hash eines Passworts (optional)

    3.2. Verschlüsseln Sie das Token mit dem privaten Schlüssel.

    3.3. Senden Sie das verschlüsselte Token an den Benutzer zurück.

  4. Wenn der Benutzer auf eine API zugreift, muss er auch sein Auth-Token übergeben.

  5. Server können die Gültigkeit des Tokens überprüfen, indem er sie mit dem öffentlichen Schlüssel des Auth-Servers entschlüsselt.

Dies ist zustandslose/RESTful-Authentifizierung.

Wenn ein Passwort-Hash eingefügt wird, sendet der Benutzer auch das unverschlüsselte Passwort zusammen mit dem Authentifizierungstoken. Der Server konnte überprüfen, ob das Kennwort mit dem zum Erstellen des Authentifizierungstokens verwendeten Kennwort übereinstimmt, indem Hashes verglichen werden. Eine sichere Verbindung mit so etwas wie HTTPS wäre notwendig. Auf der Clientseite könnte Javascript das Abrufen des Kennworts des Benutzers und das Speichern der Clientseite entweder im Arbeitsspeicher oder in einem Cookie übernehmen, möglicherweise verschlüsselt mit dem public - Schlüssel des Servers.

48
jcoffland

Um ehrlich zu sein, habe ich hier großartige Antworten gesehen, aber etwas, das mich ein bisschen stört, ist, wenn jemand das gesamte Stateless-Konzept bis zum Äußersten bringt, wo es dogmatisch wird. Es erinnert mich an die alten Smalltalk-Fans, die nur reine OO umarmen wollten und wenn etwas kein Objekt ist, dann machen Sie es falsch. Gib mir eine Pause.

Der RESTful-Ansatz soll Ihnen das Leben erleichtern und den Aufwand und die Kosten für Sitzungen reduzieren. Versuchen Sie, dies zu tun, da dies eine kluge Angelegenheit ist. Wenn Sie jedoch einer Disziplin (jeder Disziplin/Richtlinie) bis zum Äußersten folgen, wo es ist Bietet nicht mehr den gewünschten Nutzen, dann machen Sie es falsch. Einige der besten Sprachen haben heute sowohl funktionale Programmierung als auch Objektorientierung. 

Wenn Sie Ihr Problem am einfachsten lösen können, ist es, den Authentifizierungsschlüssel in einem Cookie zu speichern und an den HTTP-Header zu senden. Dann tun Sie es einfach und missbrauchen Sie es nicht. Denken Sie daran, dass Sitzungen schlecht sind, wenn sie schwer und umfangreich werden. Wenn Ihre Sitzung nur aus einer kurzen Zeichenfolge besteht, die einen Schlüssel enthält, was ist dann die große Sache?

Ich bin gerne bereit, Korrekturen in Kommentaren zu akzeptieren, aber ich sehe einfach nicht den Sinn (bisher), unser Leben unglücklich zu machen, um einfach zu vermeiden, ein großes Wörterbuch mit Hashes auf unserem Server zu führen.

36
arg20

In erster Linie ist ein RESTful-WebdienstZUSTANDSLOS(oder mit anderen WortenSITZUNGSLOS). Daher hat ein RESTful-Dienst kein Konzept für Sitzungen oder Cookies. Zur Authentifizierung oder Autorisierung im RESTful-Dienst können Sie den HTTP-Autorisierungsheader verwenden, wie in den RFC 2616-HTTP-Spezifikationen definiert. Jede einzelne Anforderung sollte den HTTP-Autorisierungsheader enthalten, und die Anforderung sollte über eine HTTPs-Verbindung (SSL) gesendet werden. Dies ist der richtige Weg, um die Authentifizierung durchzuführen und die Autorisierung von Anforderungen in einem HTTP-RESTful-Webdienst zu überprüfen. Ich habe einen RESTful-Webdienst für die Anwendung Cisco PRIME Performance Manager bei Cisco Systems implementiert. Als Teil dieses Webservices habe ich auch die Authentifizierung/Autorisierung implementiert.

Rubens Gomes.

32
user2213684

Bei "Sitzungsschlüsseln" handelt es sich sicherlich nicht um "Sitzungsschlüssel", da in der Regel auf sitzungslose Authentifizierung Bezug genommen wird, die innerhalb aller Einschränkungen von REST durchgeführt wird. Jede Anforderung ist selbstbeschreibend und enthält ausreichend Informationen, um die Anforderung selbst ohne serverseitigen Anwendungsstatus zu autorisieren.

Der einfachste Weg, dies zu erreichen, besteht darin, mit den integrierten Authentifizierungsmechanismen von HTTP in RFC 2617 zu beginnen.

22
Justin Sheehy

Der von @skrebel ( http://www.berenddeboer.net/rest/authentication.html ) .__ erwähnte "sehr aufschlussreiche" Artikel beschreibt eine verschlungene, aber wirklich gebrochene Authentifizierungsmethode.

Sie können versuchen, die Seite zu besuchen (die nur für authentifizierte Benutzer sichtbar sein soll) http://www.berenddeboer.net/rest/site/authenticated.html ohne Anmeldeinformationen.

(Sorry, ich kann die Antwort nicht kommentieren.)

Ich würde sagen, REST und Authentifizierung mischen sich einfach nicht. REST bedeutet zustandslos, aber "authentifiziert" ist ein Zustand. Sie können nicht beide auf derselben Ebene haben. Wenn Sie ein RESTful-Befürworter sind und die Zustände missbilligen, müssen Sie sich für HTTPS entscheiden (d. H. Das Sicherheitsproblem einer anderen Schicht überlassen).

15
Ji Han

Ich denke, bei der Restful-Authentifizierung wird ein Authentifizierungstoken als Parameter in der Anforderung übergeben. Beispiele sind die Verwendung von Apikeys durch Apis. Ich glaube nicht, dass die Verwendung von Cookies oder HTTP-Authentifizierung qualifiziert ist.

12
Bjorn Tipling

Update am 16. Februar 2019

Der weiter unten erwähnte Ansatz ist im Wesentlichen die Berechtigungsart "Ressourceninhaberkennwort" von OAuth2.0 . Dies ist ein einfacher Weg, um loszulegen. Bei diesem Ansatz erhält jede Anwendung in der Organisation jedoch ihre eigenen Authentifizierungs- und Autorisierungsmechanismen. Der empfohlene Ansatz ist der Berechtigungstyp "Autorisierungscode". Darüber hinaus empfahl ich in meiner vorherigen Antwort den Browser localStorage zum Speichern von Authentifizierungs-Token. Ich bin jedoch der Meinung, dass ein Cookie für diesen Zweck die richtige Option ist. Ich habe meine Gründe, die Art der Implementierung des Autorisierungscodetyps, Sicherheitsüberlegungen usw. in dieser StackOverflow-Antwort beschrieben.


Ich denke, der folgende Ansatz kann für die REST - Dienstauthentifizierung verwendet werden:

  1. Erstellen Sie eine Login-RESTful-API, um den Benutzernamen und das Kennwort für die Authentifizierung zu akzeptieren. Verwenden Sie die HTTP-Methode POST, um das Zwischenspeichern und SSL für die Sicherheit während der Übertragung zu verhindern. Bei erfolgreicher Authentifizierung gibt die API zwei JWTs zurück - ein Zugriffstoken (kürzere Gültigkeit, beispielsweise 30 Minuten) und ein Aktualisierungstoken (beispielsweise längere Gültigkeit) 24 Stunden)
  2. Der Client (eine webbasierte Benutzeroberfläche) speichert die JWTs im lokalen Speicher und übergibt das Zugriffstoken bei jedem nachfolgenden API-Aufruf im Header "Authorization: Bearer #access token"
  3. Die API überprüft die Gültigkeit des Tokens, indem das Signatur- und Ablaufdatum überprüft wird. Wenn das Token gültig ist, überprüfen Sie, ob der Benutzer (er interpretiert den "Sub" -Anspruch in JWT als Benutzernamen interpretiert) Zugriff auf die API mit einer Cache-Suche. Wenn der Benutzer zum Zugriff auf die API berechtigt ist, führen Sie die Geschäftslogik aus
  4. Wenn das Token abgelaufen ist, gibt die API den HTTP-Antwortcode 400 zurück
  5. Beim Empfang von 400/401 ruft der Client eine andere REST - API mit dem Aktualisierungstoken im Header "Authorization: Bearer #refresh token" auf, um ein neues Zugriffstoken abzurufen. 
  6. Überprüfen Sie nach Erhalt des Anrufs mit Aktualisierungstoken, ob das Aktualisierungstoken gültig ist, indem Sie die Signatur und das Ablaufdatum prüfen. Wenn das Aktualisierungstoken gültig ist, aktualisieren Sie den Zugriffsrechtcache des Benutzers aus der Datenbank, und geben Sie ein neues Zugriffstoken und ein Aktualisierungstoken zurück. Wenn das Aktualisierungstoken ungültig ist, geben Sie den HTTP-Antwortcode 400 zurück
  7. Wenn ein neues Zugriffstoken und ein Aktualisierungstoken zurückgegeben werden, fahren Sie mit Schritt 2 fort. Wenn der HTTP-Antwortcode 400 zurückgegeben wird, geht der Client davon aus, dass das Aktualisierungstoken abgelaufen ist, und fordert den Benutzer zur Eingabe von Benutzernamen und Kennwort auf
  8. Löschen Sie den lokalen Speicher, um sich abzumelden

Auf diese Weise erledigen wir den kostspieligen Vorgang, alle 30 Minuten den Cache mit benutzerspezifischen Zugriffsrechten zu laden. Wenn also ein Zugriff widerrufen wird oder ein neuer Zugriff gewährt wird, dauert es 30 Minuten, bis ein Abmelden gefolgt von einem Login erfolgt.

10
Saptarshi Basu

So geht's: Verwendung von OAuth 2.0 für die Anmeldung .

Sie können andere Authentifizierungsmethoden als die von Google verwenden, sofern diese OAuth unterstützt.

8
moshe beeri

Durch die Verwendung einer Infrastruktur mit einem öffentlichen Schlüssel, bei der die Registrierung eines Schlüssels eine ordnungsgemäße Bindung erfordert, wird sichergestellt, dass der öffentliche Schlüssel an die Person gebunden ist, der er zugewiesen ist, und zwar so, dass die Nicht-Ablehnung gewährleistet ist

Siehe http://en.wikipedia.org/wiki/Public_key_infrastructure . Wenn Sie die richtigen PKI-Standards einhalten, kann die Person oder der Agent, der den gestohlenen Schlüssel nicht ordnungsgemäß verwendet, identifiziert und gesperrt werden. Wenn der Agent ein Zertifikat verwenden muss, wird die Bindung ziemlich eng. Ein kluger und sich schnell bewegender Dieb kann fliehen, aber er hinterlässt mehr Krümel.

2
DonB.

Um diese Frage aus meinem Verständnis zu beantworten ...

Ein Authentifizierungssystem, das REST = verwendet, damit Sie die Benutzer in Ihrem System nicht wirklich verfolgen oder verwalten müssen. Dazu verwenden Sie die HTTP-Methoden POST, GET, PUT, DELETE. Wir nehmen diese 4 Methoden und betrachten sie in Bezug auf die Datenbankinteraktion als CREATE, READ, UPDATE, DELETE (im Web verwenden wir POST und GET, weil dies Ankertags derzeit unterstützen). Wenn wir also POST und GET als CREATE/READ/UPDATE/DELETE (CRUD) behandeln, können wir in unserer Webanwendung Routen entwerfen, die ableiten können, welche Aktion von CRUD wir erreichen. 

In einer Ruby on Rails-Anwendung können wir beispielsweise unsere Web-App so erstellen, dass wenn ein Benutzer, der angemeldet ist, Besuche http://store.com/account/logout besucht, der GET dieser Seite als Benutzer versucht sich abzumelden. In unserem Rails-Controller bauen wir eine Aktion auf, bei der der Benutzer abgemeldet und zur Homepage zurückgeschickt wird.

Ein GET auf der Anmeldeseite würde ein Formular ergeben. a POST auf der Anmeldeseite würde als Anmeldeversuch angesehen und die POST -Daten verwenden und zum Anmelden verwenden. 

Für mich ist es eine Praxis, HTTP-Methoden zu verwenden, die ihrer Datenbankbedeutung zugeordnet sind, und dann ein Authentifizierungssystem zu erstellen, mit dem Ziel, dass Sie keine Sitzungs-ID weiterleiten oder Sitzungen nachverfolgen müssen.

Ich lerne noch - wenn Sie etwas finden, von dem ich gesagt habe, dass es falsch ist, korrigieren Sie mich bitte, und wenn Sie mehr erfahren, posten Sie es hier. Vielen Dank.

2
mike

Tipps zum Sichern von Webanwendungen

Wenn Sie Ihre Anwendung sichern möchten, , sollten Sie auf jeden Fall HTTPS anstelle von HTTP verwenden. Dadurch wird sichergestellt, dass zwischen Ihnen und den Benutzern ein sicherer Kanal geschaffen wird, der das Sniffing der zurückgesendeten Daten verhindert die Benutzer & helfen dabei, die ausgetauschten Daten geheim zu halten.

Sie können JWTs (JSON Web Tokens) verwenden, um RESTful-APIs zu sichern. Dies hat viele Vorteile im Vergleich zu serverseitigen Sitzungen. Die Vorteile sind hauptsächlich:

1- Skalierbarer, da Ihre API-Server keine Sitzungen für jeden Benutzer verwalten müssen (was bei vielen Sitzungen eine große Belastung sein kann)

2- JWTs sind in sich abgeschlossen und verfügen über die Ansprüche, die beispielsweise die Benutzerrolle definieren und auf was er zum Datum und auf das Ablaufdatum zugreifen kann (danach ist JWT nicht gültig).

3- Einfachere Handhabung über Lastenausgleichsfunktionen und wenn Sie über mehrere API-Server verfügen, da Sie weder Sitzungsdaten gemeinsam verwenden müssen, noch müssen Sie den Server so konfigurieren, dass die Sitzung an denselben Server weitergeleitet wird. Jedes Mal, wenn eine Anfrage mit einem JWT einen Server trifft, können sie authentifiziert werden & autorisiert

4 - Weniger Druck auf Ihre Datenbank und Sie müssen nicht für jede Anforderung die Sitzungs-ID und -Daten ständig speichern und abrufen

5- Die JWTs können nicht manipuliert werden, wenn Sie einen starken Schlüssel zum Signieren der JWT verwenden, sodass Sie den Ansprüchen in der JWT, die mit der Anforderung gesendet werden, vertrauen können, ohne die Benutzersitzung überprüfen zu müssen und ob sie autorisiert ist oder nicht Sie können einfach die JWT überprüfen und dann sind Sie bereit zu wissen, wer und was dieser Benutzer tun kann.

Viele Bibliotheken bieten einfache Möglichkeiten zum Erstellen und Validieren von JWTs in den meisten Programmiersprachen. Beispiel: In node.js ist jsonwebtoken

Da die APIs von REST generell darauf abzielen, den Server statusfrei zu halten, sind JWTs mit diesem Konzept besser kompatibel, da jede Anforderung mit einem inhärenten Autorisierungstoken (JWT) gesendet wird, ohne dass der Server dies erfordert Um die Benutzersitzung im Vergleich zu Sitzungen zu verfolgen, die den Server statusorientiert machen, erinnert er sich an den Benutzer und seine Rolle. Sessions werden jedoch auch häufig verwendet und haben ihre Profis, nach denen Sie suchen können, wenn Sie möchten.

Es ist wichtig zu wissen, dass Sie die JWT mithilfe von HTTPS sicher an den Client übergeben und an einem sicheren Ort speichern müssen (z. B. im lokalen Speicher).

Sie können mehr über JWTs über diesen Link erfahren.

1
Ahmed Elkoussy