RESTful Authentifizierung

Was bedeutet RESTful Authentication und wie funktioniert es? Ich kann bei Google keinen guten Überblick finden. Mein einziges Verständnis ist, dass Sie den Sitzungsschlüssel (remeberal) in der URL übergeben, aber dies könnte schrecklich falsch sein.

Der Umgang mit der Authentifizierung in einer RESTful Client-Server-Architektur ist umstritten.

Im Allgemeinen kann dies in der SOA über HTTP-Welt erreicht werden über:

• 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 noch besser mischen, um sie bestenfalls an Ihre Softwarearchitektur anzupassen.

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

HTTP-Basisauthentifizierung über HTTPS

Diese erste Lösung, die auf dem Standard-HTTPS-Protokoll basiert, wird von den meisten Webdiensten 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, hat jedoch einige bekannte Nachteile, wie das im Browser angezeigte schreckliche Authentifizierungsfenster, das bestehen bleibt (hier gibt es keine LogOut-ähnliche Funktion), einen serverseitigen zusätzlichen CPU-Verbrauch. und die Tatsache, dass der Benutzername und das Kennwort (über HTTPS) an den Server übertragen werden (es sollte sicherer sein, das Kennwort während der Tastatureingabe nur auf der Clientseite zu belassen und als sicherer Hash auf dem Server zu speichern). .

Möglicherweise verwenden wir die Digest-Authentifizierung , sie erfordert jedoch auch HTTPS, da sie für MiM- oder Replay- Angriffe anfällig und für HTTP spezifisch ist.

Sitzung über Cookies

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

Eine Möglichkeit könnte darin bestehen, alle Daten innerhalb des Cookie-Inhalts zu verwalten. Und das Cookie wird standardmäßig auf der Serverseite behandelt (der Client versucht sogar nicht, diese Cookie-Daten zu interpretieren: Er gibt sie bei jeder aufeinanderfolgenden Anforderung einfach an den Server zurück). Bei diesen Cookie-Daten handelt es sich jedoch um Anwendungsstatusdaten. 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 meiner Meinung nach protokollunabhängig sein sollte. Es ist anfällig für MiM- oder Replay- Angriffe.

Erteilt über Token (OAuth2)

Eine Alternative besteht darin, ein Token in die HTTP-Header einzufügen, damit die Anforderung authentifiziert wird. Dies ist zum Beispiel 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 weist dieselben Probleme auf: Es ist nicht zustandslos, basiert auf HTTP-Übertragungsdetails und unterliegt vielen Sicherheitslücken - einschließlich MiM und Replay - und darf daher nur über HTTPS verwendet werden. In der Regel wird ein JWT als Token verwendet.

Authentifizierung abfragen

Die Abfrageauthentifizierung besteht darin, jede RESTful-Anforderung über einige zusätzliche Parameter im URI zu signieren. Siehe diesen Referenzartikel .

Es wurde in diesem Artikel als solches definiert:

Alle REST-Abfragen müssen authentifiziert werden, indem die Abfrageparameter in alphabetischer Reihenfolge in Kleinbuchstaben signiert werden, wobei der private Berechtigungsnachweis als Signatur-Token verwendet wird. Die Signierung sollte vor der URL erfolgen, die die Abfragezeichenfolge codiert.

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

Hier ist zum Beispiel ein generisches URI-Beispiel über den obigen Link:

GET /object?apiKey=Qwerty2010

sollte als solche übertragen werden:

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

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

Serverseitiges Daten-Caching kann immer verfügbar sein. In unserem Framework werden die Antworten beispielsweise auf SQL-Ebene und nicht auf URI-Ebene zwischengespeichert. Das Hinzufügen dieses zusätzlichen Parameters unterbricht also nicht den Cache-Mechanismus.

In diesem Artikel finden Sie einige Details zur RESTful-Authentifizierung in unserem Client-Server-ORM / SOA / MVC-Framework, das auf JSON und REST basiert. Da wir die Kommunikation nicht nur über HTTP / 1.1, sondern auch über Named Pipes oder GDI-Nachrichten (lokal) zulassen, haben wir versucht, ein wirklich RESTful-Authentifizierungsmuster zu implementieren und uns nicht auf HTTP-Spezifität (wie Header oder Cookies) zu verlassen.

Späterer Hinweis : Das Hinzufügen einer Signatur zum URI kann als schlechte Vorgehensweise angesehen werden (da sie beispielsweise in den http-Serverprotokollen angezeigt wird), sodass sie verringert werden muss, z. B. durch eine geeignete TTL, um Wiederholungen zu vermeiden. Wenn Ihre http-Protokolle jedoch gefährdet sind, treten mit Sicherheit größere Sicherheitsprobleme auf.

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

Fazit

Es ist zu schließen, dass REST nicht nur HTTP-basiert ist, auch wenn es in der Praxis meistens auch über HTTP implementiert wird. REST kann andere Kommunikationsschichten verwenden. Eine RESTful-Authentifizierung ist also nicht nur ein Synonym für die HTTP-Authentifizierung, unabhängig davon, was Google antwortet. Es sollte den HTTP-Mechanismus überhaupt nicht verwenden, sondern von der Kommunikationsschicht abstrahiert werden. Und wenn Sie HTTP-Kommunikation verwenden, gibt es dank der Let's Encrypt-Initiative keinen Grund, kein ordnungsgemäßes HTTPS zu verwenden, das zusätzlich zu einem Authentifizierungsschema erforderlich ist.

Ich bezweifle, dass die Leute, die begeistert "HTTP-Authentifizierung" riefen, jemals versucht haben, eine browserbasierte Anwendung (anstelle eines Computer-zu-Maschine-Webdienstes) mit REST zu erstellen (keine Straftat beabsichtigt - ich glaube nur nicht, dass sie jemals mit den Komplikationen konfrontiert waren). .

Bei der Verwendung der HTTP-Authentifizierung für RESTful-Dienste, die HTML-Seiten erzeugen, die in einem Browser angezeigt werden sollen, sind folgende Probleme aufgetreten:

• Der Benutzer erhält normalerweise eine hässliche, vom Browser erstellte Anmeldebox, die sehr benutzerunfreundlich ist. Sie können keine Kennwortabfrage, Hilfefelder usw. hinzufügen.
• Das Abmelden oder Anmelden unter einem anderen Namen ist ein Problem. Browser senden weiterhin Authentifizierungsinformationen an die Site, bis Sie das Fenster schließen
• Timeouts sind schwierig

Ein sehr aufschlussreicher Artikel, der diese Punkte Punkt für Punkt behandelt, ist hier , aber dies führt zu einer Menge browserspezifischer Javascript-Hackerei, Problemumgehungen für Problemumgehungen usw. Daher ist es auch nicht vorwärtskompatibel und muss daher ständig gewartet werden, wenn neue Browser veröffentlicht werden. Ich halte dieses klare und klare Design nicht für wichtig, und ich denke, es ist viel zusätzliche Arbeit und Kopfschmerzen, nur damit ich meinen Freunden mein REST-Abzeichen mit Begeisterung zeigen kann.

Ich glaube, Cookies sind die Lösung. Aber warte, Kekse sind böse, nicht wahr? Nein, das ist nicht der Fall. Die Art und Weise, wie Cookies häufig verwendet werden, ist böse. Ein Cookie selbst ist nur eine clientseitige Information, genau wie die HTTP-Authentifizierungsinformationen, die der Browser beim Surfen nachverfolgen würde. Und diese clientseitigen Informationen werden bei jeder Anforderung an den Server gesendet, genau wie die HTTP-Authentifizierungsinformationen. Konzeptionell besteht der einzige Unterschied darin, dass der Inhalt dieses clientseitigen Status vom Server als Teil seiner Antwort bestimmt werden kann.

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

• Eine Sitzung ordnet einen Schlüssel einer Benutzer-ID zu (und möglicherweise einen Zeitstempel für die letzte Aktion für Zeitüberschreitungen).
• Wenn eine Sitzung vorhanden ist, bedeutet dies, dass der Schlüssel gültig ist.
• Anmelden bedeutet POSTEN an / Sitzungen, ein neuer Schlüssel wird als Cookie gesetzt
• Abmelden bedeutet LÖSCHEN / Sitzungen / {Schlüssel} (mit dem überladenen POST denken Sie daran, wir sind ein Browser, und HTML 5 ist noch ein langer Weg)
• Die Authentifizierung erfolgt durch Senden des Schlüssels als Cookie bei jeder Anforderung und Überprüfen, ob die Sitzung vorhanden 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 weiterhin zurücksendet, anstatt dass der Client ihn anhand der eingegebenen Anmeldeinformationen berechnet.

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

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

Zu diesem Thema wird hier bereits von guten Leuten genug gesagt. Aber hier sind meine 2 Cent.

Es gibt zwei 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 / Clients sind entweder die Menschen oder die Maschinen.

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

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

Beachten Sie Folgendes: Sie haben eine Daten- / Informationsplattform mit REST-APIs verfügbar gemacht. 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) eine Web-App, (2) eine mobile App und (3) eine Drittanbieteranwendung darauf zugreifen. Am Ende führt sogar eine Kette von MTMs zu HTM - richtig. So bleiben menschliche Benutzer an der Spitze der Informationskette.

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

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

Weg-1:

1. Es gibt zunächst kein Login. Jede Anfrage führt die Anmeldung durch
2. Der Client sendet bei jeder Anforderung seine identifizierenden Parameter + die anforderungsspezifischen Parameter
3. Die REST-API nimmt sie, dreht sich um, pingt den Benutzerspeicher (was auch immer das ist) und bestätigt die Authentifizierung
4. Wenn die Authentifizierung eingerichtet ist, wird die Anforderung bearbeitet. Andernfalls wird mit dem entsprechenden HTTP-Statuscode abgelehnt
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 Authentifizierungsanforderung
2. Eine Login-REST-API verarbeitet alle diese Anforderungen
3. Es nimmt Authentifizierungsparameter (API-Schlüssel, UID / PWD oder was auch immer Sie wählen) auf und überprüft die Authentifizierung anhand des Benutzerspeichers (LDAP, AD oder MySQL DB usw.).
4. Wenn dies überprüft wurde, wird ein Authentifizierungstoken erstellt und an den Client / Anrufer zurückgegeben
5. Der Aufrufer sendet dann dieses Authentifizierungstoken + anforderungsspezifische Parameter bei jeder nachfolgenden Anforderung an andere Geschäfts-REST-APIs, bis er abgemeldet ist oder bis die Lease abläuft

In Way-2 benötigen die REST-APIs eindeutig eine Möglichkeit, das Token als gültig zu erkennen und ihm zu vertrauen. Die Anmelde-API hat die Authentifizierungsüberprüfung durchgeführt. Daher muss dieser "Valet-Schlüssel" von anderen REST-APIs in Ihrem Katalog als vertrauenswürdig eingestuft werden.

Dies bedeutet natürlich, dass der Authentifizierungsschlüssel / das Authentifizierungs-Token gespeichert und von den REST-APIs gemeinsam genutzt werden muss. Dieses gemeinsam genutzte, vertrauenswürdige Token-Repository kann lokal / zusammengeschlossen 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, was der Weg-1 ist, müssen wir akzeptieren, dass für alle eingehenden Anfragen ein Authentifizierungsvorgang 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 die Übereinstimmung von UID und PWD zu überprüfen. Oder um Hash-Übereinstimmungen zu verschlüsseln und durchzuführen (im AWS-Stil). Und architektonisch muss jede REST-API dies, wie ich vermute, mithilfe eines gemeinsamen Back-End-Anmeldedienstes durchführen. Wenn Sie dies nicht tun, verunreinigen Sie den Authentifizierungscode überall. Ein großes Durcheinander.

Also mehr Schichten, mehr Latenz.

Nehmen Sie nun Way-1 und bewerben Sie sich bei HTM. Interessiert es Ihren (menschlichen) Benutzer wirklich, wenn 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 Auth / Login-Seite aufrufen. Viel Glück, wenn Sie Kunden haben. Sie speichern die Anmeldeinformationen also gleich zu Beginn irgendwo auf der Clientseite im Browser und senden sie bei jeder Anfrage. 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 nie bemerken. Es wurde also kein Schaden angerichtet.

Was ist, wenn wir Way-1 auf MTM anwenden? In diesem Fall können wir, da es sich um eine Maschine handelt, diesen Typen zum Teufel langweilen, indem wir ihn bitten, bei jeder Anfrage Authentifizierungsinformationen einzureichen. Niemanden interessierts! Das Ausführen von Way-2 auf MTM ruft keine besondere Reaktion hervor. Es ist eine verdammte Maschine. Es könnte weniger interessieren!

Die Frage ist also wirklich, was Ihren Bedürfnissen entspricht. Staatenlosigkeit hat einen Preis zu zahlen. Zahlen Sie den Preis und fahren Sie fort. Wenn Sie Purist werden 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.

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. Stellen 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 Authentifizierungstoken übergeben.

5. Server können überprüfen, ob das Token gültig ist, indem sie es mit dem öffentlichen Schlüssel des Authentifizierungsservers entschlüsseln.

Dies ist eine zustandslose / RESTful-Authentifizierung.

Beachten Sie, dass der Benutzer, wenn ein Kennwort-Hash enthalten wäre, auch das unverschlüsselte Kennwort zusammen mit dem Authentifizierungstoken senden würde. Der Server konnte durch Vergleichen von Hashes überprüfen, ob das Kennwort mit dem Kennwort übereinstimmt, mit dem das Authentifizierungstoken erstellt wurde. Eine sichere Verbindung mit so etwas wie HTTPS wäre notwendig. Javascript auf der Clientseite kann das Abrufen des Benutzerkennworts und das Speichern auf der Clientseite entweder im Speicher oder in einem Cookie verarbeiten, das möglicherweise mit dem öffentlichen Schlüssel des Servers verschlüsselt ist .

Um ehrlich zu sein, habe ich hier großartige Antworten gesehen, aber etwas, das mich ein bisschen stört, ist, wenn jemand das gesamte Staatenlose-Konzept auf ein Extrem bringt, wo es dogmatisch wird. Es erinnert mich an diese alten Smalltalk-Fans, die nur reines OO annehmen wollten, und wenn etwas kein Objekt ist, dann machst du es falsch. Gib mir eine Pause.

Der RESTful-Ansatz soll Ihnen das Leben erleichtern und den Aufwand und die Kosten für Sitzungen senken. Versuchen Sie, ihn zu befolgen, da dies eine kluge Sache ist, aber sobald Sie einer Disziplin (einer Disziplin / Richtlinie) folgen, bis zum Äußersten bietet nicht mehr den Nutzen, für den es gedacht war, dann machst du es falsch. Einige der besten Sprachen haben heute sowohl funktionale Programmierung als auch Objektorientierung.

Wenn Sie Ihr Problem am einfachsten lösen können, indem Sie den Authentifizierungsschlüssel in einem Cookie speichern und im HTTP-Header senden, missbrauchen Sie ihn einfach nicht. Denken Sie daran, dass Sitzungen schlecht sind, wenn sie schwer und groß 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 offen für Korrekturen in Kommentaren, aber ich sehe (bis jetzt) ​​keinen Sinn darin, unser Leben unglücklich zu machen, um einfach zu vermeiden, ein großes Wörterbuch mit Hashes auf unserem Server zu führen.

In erster Linie ist ein RESTful-Webdienst STATELESS (oder mit anderen Worten SESSIONLESS)). Daher verfügt ein RESTful-Service nicht über ein Konzept für Sitzungen oder Cookies und sollte dies auch nicht tun. Die Authentifizierung oder Autorisierung im RESTful-Dienst erfolgt mithilfe des HTTP-Autorisierungsheaders, wie in den RFC 2616-HTTP-Spezifikationen definiert. Jede einzelne Anforderung sollte den HTTP-Autorisierungsheader enthalten, und die Anforderung sollte über eine HTTP-Verbindung (SSL) gesendet werden. Dies ist der richtige Weg, um eine Authentifizierung durchzuführen und die Autorisierung von Anforderungen in einem HTTP RESTful-Webdienst zu überprüfen. Ich habe einen RESTful-Webdienst für die Cisco PRIME Performance Manager-Anwendung bei Cisco Systems implementiert. Und als Teil dieses Webdienstes habe ich auch die Authentifizierung / Autorisierung implementiert.

Es geht sicherlich nicht um "Sitzungsschlüssel", da es im Allgemeinen verwendet wird, um auf die sitzungslose Authentifizierung zu verweisen, die innerhalb aller Einschränkungen von REST durchgeführt wird. Jede Anforderung ist selbstbeschreibend und enthält genügend Informationen, um die Anforderung ohne serverseitigen Anwendungsstatus selbst zu autorisieren.

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

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

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

(Entschuldigung, ich kann die Antwort nicht kommentieren.)

Ich würde sagen, REST und Authentifizierung passen einfach nicht zusammen. REST bedeutet zustandslos, aber "authentifiziert" ist ein Zustand. Sie können nicht beide auf derselben Ebene haben. Wenn Sie ein RESTful-Anwalt sind und Staaten missbilligen, müssen Sie sich für HTTPS entscheiden (dh das Sicherheitsproblem einer anderen Ebene überlassen).

Ich denke, bei einer erholsamen 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 auth qualifiziert ist.

Update am 16.02.2019

Der zuvor erwähnte Ansatz ist im Wesentlichen der Grant-Typ "Resource Owner Password Credential" von OAuth2.0 . Dies ist eine einfache Möglichkeit, um loszulegen. Bei diesem Ansatz verfügt jedoch jede Anwendung in der Organisation über eigene Authentifizierungs- und Autorisierungsmechanismen. Der empfohlene Ansatz ist der Grant-Typ "Authorization Code". Außerdem habe ich in meiner früheren Antwort unten den Browser localStorage zum Speichern von Authentifizierungstoken empfohlen. Ich bin jedoch zu der Überzeugung gelangt, dass Cookies die richtige Option für diesen Zweck sind. In dieser StackOverflow-Antwort habe ich meine Gründe, den Implementierungsansatz für den Berechtigungscode-Grant-Typ, Sicherheitsaspekte usw. detailliert beschrieben .

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

1. Erstellen Sie eine RESTful-Anmelde-API, um Benutzername und Kennwort für die Authentifizierung zu akzeptieren. Verwenden Sie die HTTP-POST-Methode, um Caching 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, z. B. 30 Minuten) und ein Aktualisierungstoken (längere Gültigkeit, z. B. 24 Stunden).
2. Der Client (eine webbasierte Benutzeroberfläche) speichert die JWTs im lokalen Speicher und übergibt bei jedem nachfolgenden API-Aufruf das Zugriffstoken im Header "Authorization: Bearer #access token"
3. Die API überprüft die Gültigkeit des Tokens, indem sie die Signatur und das Ablaufdatum überprüft. Wenn das Token gültig ist, überprüfen Sie, ob der Benutzer (der den "Unter" -Anspruch in JWT als Benutzernamen interpretiert) mit einer Cache-Suche Zugriff auf die API hat. Wenn der Benutzer berechtigt ist, auf die API zuzugreifen, führen Sie die Geschäftslogik aus
4. Wenn das Token abgelaufen ist, gibt die API den HTTP-Antwortcode 400 zurück
5. Der Client ruft beim Empfang von 400/401 eine andere REST-API mit dem Aktualisierungstoken im Header "Authorization: Bearer #refresh token" auf, um ein neues Zugriffstoken abzurufen.
6. Überprüfen Sie beim Empfang des Anrufs mit dem Aktualisierungstoken, ob das Aktualisierungstoken gültig ist, indem Sie die Signatur und das Ablaufdatum überprüfen. Wenn das Aktualisierungstoken gültig ist, aktualisieren Sie den Zugriffsrechtscache des Benutzers aus der Datenbank und geben Sie das neue Zugriffstoken und das Aktualisierungstoken zurück. Wenn das Aktualisierungstoken ungültig ist, geben Sie den HTTP-Antwortcode 400 zurück
7. Wenn ein neues Zugriffstoken und ein neues 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 fragt den Benutzer nach Benutzername und Kennwort
8. Löschen Sie zum Abmelden den lokalen Speicher

Mit diesem Ansatz erledigen wir den teuren Vorgang, den Cache alle 30 Minuten mit benutzerspezifischen Zugriffsrechtsdetails zu laden. Wenn also ein Zugriff widerrufen oder ein neuer Zugriff gewährt wird, dauert es 30 Minuten, bis er reflektiert oder abgemeldet und anschließend angemeldet wird.

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

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

Durch die Verwendung einer Infrastruktur für öffentliche 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 auf eine Weise, die eine Nicht-Zurückweisung gewährleistet

Siehe http://en.wikipedia.org/wiki/Public_key_infrastructure . Wenn Sie die richtigen PKI-Standards befolgen, kann die Person oder der Agent, die 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 entkommen, aber sie hinterlassen mehr Krümel.

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

Ein Authentifizierungssystem, das REST verwendet, sodass Sie die Benutzer in Ihrem System nicht tatsächlich verfolgen oder verwalten müssen. Dies erfolgt mit den HTTP-Methoden POST, GET, PUT, DELETE. Wir nehmen diese 4 Methoden und betrachten sie in Bezug auf die Datenbankinteraktion als CREATE, READ, UPDATE, DELETE (aber im Web verwenden wir POST und GET, da dies derzeit von Ankertags unterstützt wird). Wenn Sie also POST und GET als unser CREATE / READ / UPDATE / DELETE (CRUD) behandeln, können wir in unserer Webanwendung Routen entwerfen, die ableiten können, welche CRUD-Aktion wir erzielen.

In einer Ruby on Rails-Anwendung können wir beispielsweise unsere Web-App so erstellen, dass ein angemeldeter Benutzer http://store.com/account/logout besucht das GET dieser Seite als der Benutzer angezeigt wird, der versucht, sich abzumelden . In unserem Rails-Controller erstellen wir eine Aktion, mit der der Benutzer abgemeldet und an die Startseite zurückgesendet wird.

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

Für mich ist es üblich, HTTP-Methoden zu verwenden, die ihrer Datenbankbedeutung zugeordnet sind, und dann ein Authentifizierungssystem zu erstellen, bei dem Sie keine Sitzungs-IDs weitergeben oder Sitzungen verfolgen 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 zurück. Vielen Dank.

Tipps zum Sichern von Webanwendungen

Wenn Sie Ihre Anwendung sichern möchten, sollten Sie auf jeden Fall HTTPS anstelle von HTTP verwenden . Dies stellt sicher, dass ein sicherer Kanal zwischen Ihnen und den Benutzern erstellt wird, der verhindert, dass die an die Benutzer gesendeten Daten abgehört werden, und dass die Daten erhalten bleiben vertraulich ausgetauscht.

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

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

2- JWTs sind in sich geschlossen und haben die Ansprüche, die zum Beispiel die Benutzerrolle definieren und auf die er zugreifen kann und die zum Datum und Ablaufdatum ausgestellt wurden (danach ist JWT nicht mehr gültig).

3- Einfachere Handhabung über Load-Balancer hinweg. Wenn Sie über mehrere API-Server verfügen, müssen Sie weder Sitzungsdaten freigeben noch den Server so konfigurieren, dass die Sitzung an denselben Server weitergeleitet wird, wenn eine Anforderung mit einem JWT einen Server trifft, kann diese authentifiziert werden & autorisiert

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

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

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

Da REST-APIs im Allgemeinen darauf abzielen, den Server zustandslos zu halten, sind JWTs mit diesem Konzept besser kompatibel, da jede Anforderung mit einem eigenständigen Autorisierungstoken (JWT) gesendet wird. gesendet wird, ohne dass der Server die Benutzersitzung im Vergleich zu Sitzungen, in denen der Server ausgeführt wird, verfolgen muss Server statusbehaftet, damit er sich an den Benutzer und seine Rolle erinnert. Sitzungen sind jedoch auch weit verbreitet und haben ihre Vorteile, nach denen Sie suchen können, wenn Sie möchten.

Eine wichtige Sache, die Sie beachten sollten, ist, dass Sie das JWT mithilfe von HTTPS sicher an den Client senden und an einem sicheren Ort speichern müssen (z. B. im lokalen Speicher).

Weitere Informationen zu JWTs finden Sie unter diesem Link