RESTful-Authentifizierung

Question

Was bedeutet RESTful Authentication und wie funktioniert es? Ich kann bei Google keinen guten Überblick finden. Ich verstehe nur, dass man den Sitzungsschlüssel (remeberal) in der URL übergibt, aber das könnte schrecklich falsch sein.

Answer 1

In erster Linie ist ein RESTful Web Service STATELESS (oder mit anderen Worten, SESSIONLESS ). Daher hat ein RESTful-Dienst kein Konzept von Sitzungen oder Cookies und sollte dies auch nicht haben. Die Authentifizierung oder Autorisierung in einem RESTful-Dienst erfolgt über den HTTP-Autorisierungs-Header, der in den RFC 2616 HTTP-Spezifikationen definiert ist. Jede einzelne Anfrage sollte den HTTP-Autorisierungs-Header enthalten, und die Anfrage sollte über eine HTTPs-Verbindung (SSL) gesendet werden. Dies ist der richtige Weg, um die Authentifizierung durchzuführen und die Autorisierung von Anfragen in einem HTTP RESTful Web Service 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.

Answer 2

Es geht sicherlich nicht um "Sitzungsschlüssel", wie sie im Allgemeinen für die sitzungslose Authentifizierung verwendet werden, die innerhalb aller Beschränkungen von REST durchgeführt wird. Jede Anfrage ist selbstbeschreibend und enthält genügend Informationen, um die Anfrage selbst zu autorisieren, ohne dass ein serverseitiger Anwendungsstatus vorliegt.

Am einfachsten ist es, mit den eingebauten Authentifizierungsmechanismen von HTTP in RFC 2617 .

Answer 3

Aktualisiert am 16-Feb-2019

Der weiter unten erwähnte Ansatz ist im Wesentlichen ein "Resource Owner Password Credential" Grant-Typ OAuth2.0 . Dies ist ein einfacher Weg, um in Gang zu kommen. Bei diesem Ansatz wird jedoch jede Anwendung in der Organisation ihre eigenen Authentifizierungs- und Autorisierungsmechanismen haben. Der empfohlene Ansatz ist der Grant-Typ "Autorisierungscode". Außerdem habe ich in meiner früheren Antwort unten den Browser localStorage für die Speicherung von Authentifizierungs-Tokens empfohlen. Ich bin jedoch zu der Überzeugung gelangt, dass Cookies die richtige Option für diesen Zweck sind. Ich habe meine Gründe, den Ansatz für die Implementierung des Berechtigungscodes, die Sicherheitsüberlegungen usw. ausführlich in diese StackOverflow-Antwort .

---

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

1. Erstellen Sie eine RESTful-API für die Anmeldung, die Benutzernamen und Kennwort zur Authentifizierung akzeptiert. Verwenden Sie die HTTP-POST-Methode, um Zwischenspeicherung und SSL für die Sicherheit während der Übertragung zu verhindern. Bei erfolgreicher Authentifizierung gibt die API zwei JWTs zurück - ein Access-Token (kürzere Gültigkeit, z. B. 30 Minuten) und ein Refresh-Token (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"-Header
3. Die API prüft die Gültigkeit des Tokens durch Überprüfung der Signatur und des Ablaufdatums. Ist das Token gültig, prüft sie, ob der Benutzer (sie interpretiert die Angabe "sub" im JWT als Benutzernamen) Zugang zur API hat, indem sie im Cache nachschaut. Wenn der Benutzer zum Zugriff auf die API berechtigt ist, wird die Geschäftslogik ausgeführt
4. Wenn das Token abgelaufen ist, gibt die API den HTTP-Antwortcode 400 zurück.
5. Wenn der Client 400/401 erhält, ruft er eine andere REST-API mit dem Refresh-Token in "Authorization: Bearer #refresh token"-Header auf, um ein neues Zugriffstoken zu erhalten.
6. Beim Empfang des Aufrufs mit Refresh-Token prüfen Sie, ob das Refresh-Token gültig ist, indem Sie die Signatur und das Ablaufdatum überprüfen. Wenn das Refresh-Token gültig ist, wird der Zugriffsrechts-Cache des Benutzers aus der DB aktualisiert und ein neues Zugriffstoken und Refresh-Token zurückgegeben. Wenn das Refresh-Token ungültig ist, wird der HTTP-Antwortcode 400 zurückgegeben.
7. Wenn ein neues Zugriffstoken und ein Refresh-Token zurückgegeben werden, fahren Sie mit Schritt 2 fort. Wenn der HTTP-Antwortcode 400 zurückgegeben wird, geht der Client davon aus, dass das Refresh-Token abgelaufen ist, und fragt den Benutzer nach Benutzername und Passwort
8. Zum Abmelden den lokalen Speicher leeren

Mit diesem Ansatz führen wir alle 30 Minuten den kostspieligen Vorgang des Ladens des Caches mit benutzerspezifischen Zugriffsrechtsdetails durch. Wenn also ein Zugang widerrufen oder ein neuer Zugang gewährt wird, dauert es 30 Minuten, bis dies reflektiert wird oder ein Logout gefolgt von einem Login erfolgt.

Answer 4

Der von @skrebel erwähnte "sehr aufschlussreiche" Artikel ( http://www.berenddeboer.net/rest/authentication.html ) erörtert eine komplizierte, aber wirklich kaputte Methode der Authentifizierung.

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 jegliche Anmeldedaten.

(Leider kann ich die Antwort nicht kommentieren.)

Ich würde sagen, REST und Authentifizierung passen einfach nicht zusammen. REST bedeutet zustandslos, aber "authentifiziert" ist ein Zustand. Man kann nicht beides auf der gleichen Ebene haben. Wenn Sie ein Verfechter von REST sind und Zustände ablehnen, dann müssen Sie HTTPS verwenden (d. h. die Sicherheitsfrage einer anderen Schicht überlassen).

Answer 5

Ich denke, die Restful-Authentifizierung beinhaltet die Übergabe eines Authentifizierungs-Tokens als Parameter in der Anfrage. Beispiele sind die Verwendung von apikeys durch api's. Ich glaube nicht, dass die Verwendung von Cookies oder http-Auth qualifiziert.