Frage

Was bedeutet RESTful Authentifizierung bedeuten und wie funktioniert es? Ich kann nicht einen guten Überblick über Google finden. Mein einziges Verständnis ist, dass Sie den Sitzungsschlüssel (remeberal) in der URL übergeben, aber das könnte schief sein.

War es hilfreich?

Lösung

Wie die Authentifizierung in einer RESTful Client-Server-Architektur zu handhaben ist umstritten.

Im Allgemeinen kann es über im SOA über HTTP Welt erreicht werden:

  • HTTP Basis Authentifizierung über HTTPS;
  • Cookies und Session-Management;
  • Token in HTTP-Header (z OAuth 2.0 + JWT);
  • Abfrage-Authentifizierung mit zusätzlichen Signaturparametern.

Sie werden sich anpassen müssen, oder noch besser, diese Techniken zu mischen, Ihre Software-Architektur im besten entsprechen.

Jedes Authentifizierungsschema hat seine eigenen Vor- und Nachteile, je nach Zweck Ihrer Sicherheitspolitik und Softwarearchitektur.

HTTP Basis Authentifizierung über HTTPS

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

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

Es ist einfach zu implementieren, als Standard verfügbar sind auf allen Browsern, aber einige bekannte Nachteile hat, wie das schreckliche Fenster Authentifizierung auf dem Browser angezeigt, die fortbestehen (es gibt keine LogOut ähnliche Funktion hier), einige serverseitige Zusatz CPU-Verbrauch und die Tatsache, dass der Benutzer-Name und das Passwort übertragen werden (über HTTPS) in den Server (es soll sicherer sein das Passwort nur auf der Client-Seite, während der Tastatureingabe bleiben zu lassen und als sichere Hash gespeichert werden auf der Server).

Wir können verwenden Digest Authentication , aber es erfordert auch HTTPS, da es anfällig ist auf < a href = "http://en.wikipedia.org/wiki/Man-in-the-middle_attack" rel = "noreferrer"> MiM- oder Replay Angriffe und ist spezifisch für HTTP.

Session mit Hilfe von Cookies

Um ehrlich zu sein, eine Sitzung auf dem Server verwaltet nicht wirklich Stateless.

Eine Möglichkeit könnte sein, alle Daten im Cookie Inhalt zu halten. Und durch Design, das Cookie auf der Server-Seite behandelt wird (Client, in der Tat, versucht auch nicht diese Cookie-Daten zu interpretieren: es gibt ihm nur zurück an den Server bei jeder aufeinanderfolgenden Anfrage). Aber diese Cookie-Daten sind die Anwendung Statusdaten, so dass der Client sollte es verwalten, nicht der Server, in einer reinen Stateless Welt. 

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

Die Cookie-Technik selbst ist HTTP-verknüpft, so ist es nicht wirklich RESTful, welches Protokoll-unabhängig sein sollte, IMHO. Es ist anfällig für MiM- oder Replay Angriffe.

Zugegeben über Token (OAuth2)

Eine Alternative ist ein Token innerhalb der HTTP-Header zu setzen, so dass die Anforderung authentifiziert wird. Dies ist, was OAuth 2.0 der Fall ist, zum Beispiel. Siehe der RFC 6749 : 

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

Kurz gesagt, das ist sehr ähnlich wie bei einem Cookie und leidet an den gleichen Fragen: nicht staatenlos, auf HTTP-Übertragung Details zu verlassen und unter viele Sicherheitslücken - einschließlich MiM- und Replay - so ist nur über HTTPS verwendet werden. Typischerweise wird ein JWT als Token verwendet wird.

Abfrage Authentication

Abfrage-Authentifizierung besteht jede RESTful Anforderung über einige zusätzliche Parameter auf den URI bei der Unterzeichnung. Siehe dieser Referenzartikel .

Es wurde definiert als solche in diesem Artikel:

  

Alle REST-Abfragen müssen, indem Sie sich die Abfrageparameter authentifiziert werden   in Kleinbuchstaben, alphabetisch sortiert die privaten Anmeldeinformationen sortiert mit   wie die Unterzeichnung Token. Unterzeichnung sollte erfolgen, bevor URL der Codierung   Query-String.

Diese Technik is vielleicht mehr kompatibel mit einer Stateless-Architektur und kann auch mit einem Licht Session-Management implementiert wird (In-Memory-Sitzungen statt DB Persistenz verwendet wird).

Zum Beispiel, hier ist eine generische URI Probe aus dem obigen Link: 

GET /object?apiKey=Qwerty2010

sollten als solche übertragen werden: 

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

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

Die serverseitige Daten-Caching kann immer verfügbar sein. Zum Beispiel in unserem Rahmen, zwischenzuspeichern wir die Antworten auf SQL-Ebene, nicht auf der URI-Ebene. So das Hinzufügen dieser zusätzlichen Parameter nicht den Cache-Mechanismus brechen.

Siehe diesem Artikel für einige Details über RESTful Authentifizierung in unserem Client-Server-ORM / SOA / MVC-Framework, basierend auf JSON und REST. Da wir zulassen, dass die Kommunikation nicht nur über HTTP / 1.1, aber auch Named Pipes oder GDI-Nachrichten (lokal), haben wir versucht, ein wirklich RESTful Authentifizierung Muster zu implementieren, und nicht auf HTTP-Spezifität verlassen (wie Kopf- oder Cookies).

Später Hinweis: : eine Signatur in den URI Hinzufügen kann als schlechte Praxis gesehen werden (da zum Beispiel wird es in den http-Server-Protokollen angezeigt werden), so hat es abgemildert werden, z.B. durch eine geeignete TTL Replays zu vermeiden. Aber wenn Ihr http Protokolle gefährdet sind, werden Sie sicherlich größere Sicherheitsprobleme haben.

In der Praxis die kommenden MAC-Token-Authentifizierung für OAuth 2.0 kann eine enorme Verbesserung in Bezug auf die „Zugegeben von Token“ aktuellen Regelung. Aber das ist immer noch ein work in progress und an HTTP Übertragung gebunden.

Fazit

Es lohnt Schlussfolgerung gelangt, dass REST nicht nur HTTP-basierte, auch wenn in der Praxis, sondern auch meist HTTP implementiert über. REST können andere Kommunikationsschichten verwenden. So eine RESTful Authentifizierung ist nicht nur ein Synonym für die HTTP-Authentifizierung, unabhängig von Google Antworten. Es sollte auch nicht den HTTP-Mechanismus überhaupt verwenden, sondern wird von der Kommunikationsschicht abstrahiert werden. Und wenn Sie die HTTP-Kommunikation verwenden, dank der Initiative Let Encrypt gibt es keinen Grund, nicht ordnungsgemäßen Verwendung von HTTPS, die erforderlich ist, zusätzlich zu jedem Authentifizierungsschema.

Andere Tipps

Ich bezweifle, ob die Leute begeistert „HTTP-Authentifizierung“ rief jemals versucht, ein Browser-basierte Anwendung zu machen (statt einer Maschine-zu-Maschine-Web-Service) mit REST (Nichts für ungut - ich glaube einfach nicht, dass sie jemals konfrontiert die Komplikationen).

Probleme ich bei der Verwendung von HTTP-Authentifizierung auf RESTful Services gefunden, die HTML-Seiten produzieren in einem Browser angezeigt werden sollen:

  • Benutzer erhalten typischerweise eine hässliche browser gemacht Login-Box, die sehr benutzerunfreundlich ist. Sie können nicht durch ein Passwort Retrieval hinzufügen, Hilfe-Boxen, und so weiter.
  • abzumelden oder unter einem anderen Namen anmelden ist ein Problem - Browser hält Authentifizierungsinformationen an die Website senden, bis Sie das Fenster
    • schließen
  • Timeouts sind schwer

Ein sehr interessanter Artikel, der diesen Punkt für Punkt greift hier , aber diese Ergebnisse in einem Los von browserspezifischen JavaScript Hacks, Workarounds für Abhilfen, et cetera. Als solches ist es auch nicht aufwärtskompatibel, so wird ein ständige Wartung erfordert als neuer Browser freigegeben werden. Ich glaube nicht, dass sauberes und klares Design, und ich fühle es eine Menge zusätzlicher Arbeit und Kopfschmerzen nur so, dass ich mit Begeisterung meiner REST-Abzeichen zu meinen Freunden zeigen.

Ich glaube, dass Cookies die Lösung ist. Aber warten Sie, Cookies sind böse, nicht wahr? Nein, sie sind nicht, werden die Art und Weise Cookies häufig verwendet wird, ist das Böse. Ein Cookie selbst ist nur ein Stück clientseitige Informationen, genauso wie die HTTP-Authentifizierung Info, dass der Browser der Spur halten würde, während Sie surfen. Und dieses Stück clientseitige Informationen wird bei jeder Anfrage an den Server gesendet, wieder wie die Info-HTTP-Authentifizierung wäre. Konzeptionell ist der einzige Unterschied, dass die Inhalt dieses Stück clientseitigen Zustand kann durch die bestimmt werden Server als Teil seiner Antwort.

Durch die Sitzungen eine RESTful Ressource nur mit den folgenden Regeln zu machen:

  • A Sitzung ordnet einen Schlüssel für einen Benutzer-ID (und möglicherweise einen Last-Action-Zeitstempel für Timeouts)
  • Wenn ein Sitzung vorhanden ist, dann bedeutet das, dass der Schlüssel gültig ist.
  • Anmelden bedeutet POSTen zu / Sitzungen, ein neuer Schlüssel wird als Cookie gesetzt
  • Logout bedeutet deleteing / sessions / {key} (mit dem überladenen POST, denken Sie daran, wir sind ein Browser und HTML 5 ist ein langer Weg zu gehen noch)
  • Die Authentifizierung erfolgt durch Senden des Schlüssels als Cookie bei jeder Anfrage und prüfen, ob die Sitzung vorhanden und gültig ist

Der einzige Unterschied zu HTTP-Authentifizierung, jetzt ist, dass der Authentifizierungsschlüssel von dem Server und auf den Client generiert wird, der sie zurückschicken hält, anstelle dem Kunden aus den eingegebenen Anmeldeinformationen zu berechnen.

converter42 fügt hinzu, dass, wenn https (welche wir sollten), ist es wichtig, dass das Cookie seines sicherer Flag gesetzt hat, so dass die Authentifizierung info nie über eine nicht sichere Verbindung gesendet wird. Großer Punkt hatte es selbst nicht gesehen.

Ich glaube, dass dies eine ausreichende Lösung, die funktioniert gut, aber ich muß zugeben, dass ich von einem Sicherheitsexperten nicht genug bin in diesem Schema mögliche Löcher zu identifizieren - alles, was ich weiß, ist, dass Hunderte von Nicht-RESTful Web-Anwendungen verwenden im wesentlichen die gleichen Login-Protokoll ($ _SESSION in PHP, Http in Java EE, etc.). Die Cookie-Header Inhalte werden einfach verwendet, um eine serverseitige Ressource zu adressieren, wie eine accept-Sprache verwendet werden könnte Übersetzungs-Ressourcen zugreifen zu können, und so weiter. Ich glaube, dass es das gleiche ist, aber vielleicht andere nicht? Was denken Sie, Jungs?

schon genug zu diesem Thema durch gute Leute hier gesagt wird. Aber hier ist mein 2 Cent.

Es gibt 2 Arten der Interaktion:

  1. Mensch-zu-Maschine (HTM)
  2. Maschine-zu-Maschine (MTM)

Die Maschine ist der gemeinsame Nenner, wie der Rest APIs ausgedrückt, und die Schauspieler / Kunden entweder die Menschen oder die Maschinen zu sein.

Nun, in einer wirklich RESTful-Architektur, impliziert der Begriff der Staatenlosigkeit dass alle relevanten Anwendungszustände (die Client-Seite Zustände Bedeutung) muss mit jedem und jeder Anfrage geliefert werden. Durch die relevant ist gemeint, dass das, was von dem REST-API erforderlich ist, die Anforderung und dazu dienen, eine angemessene Antwort zu verarbeiten.

Wenn wir dies im Rahmen betrachten Mensch-zu-Maschine-Anwendungen „Browser-basierte“, wie Skrebbel oben weist darauf hin, dies bedeutet, dass die (Web-) Anwendung im Browser ausgeführt wird ihre Zustand und relevante Informationen senden mit jeder Anforderung an die back-End-REST-APIs macht.

Bedenken Sie: Sie haben eine Daten- / Informationsplattform ausgesetzt Asset von REST-APIs. Vielleicht haben Sie eine Self-Service-BI-Plattform, die alle Daten Würfel verarbeitet. Aber Sie wollen Ihre (human) Kunden einen Zugang über (1) Web-App, (2) mobile app, und (3) einige 3rd-Party-Anwendung. Am Ende führt sogar Kette von MTMS zu HTM up - rechts. So bleiben menschliche Benutzer an der Spitze der Informationskette.

In den ersten zwei Fällen haben Sie einen Fall für die Mensch-zu-Maschine-Interaktion, die Informationen tatsächlich durch einen menschlichen Benutzer verbraucht werden. Im letzten Fall müssen Sie ein Maschinenprogramm den REST-APIs raubend.

Das Konzept der Authentifizierung gilt auf der ganzen Linie. Wie werden Sie diese so auszugestalten, dass Ihre REST-APIs in einem einheitlichen zugegriffen wird, gesichert Art und Weise? So wie ich das sehe, gibt es 2 Möglichkeiten:

Way-1:

  1. Es ist keine Anmeldung, zu beginnen. Jede Anfrage führt die Login
  2. Der Client sendet seine Identifizierung Parameter + die Anfrage spezifischen Parameter mit jeder Anforderung
  3. Der REST API nimmt sie, dreht sich um, ein Ping-Signal der Benutzerspeicher (Was auch immer das ist) und bestätigt die Auth
  4. Wenn die Auth eingerichtet ist, bedient die Anfrage; andernfalls verweigert mit entsprechendem HTTP-Statuscode
  5. Wiederholen Sie die oben für jede Anfrage über alle REST-APIs in Ihrem Katalog

Way-2:

  1. Der Client beginnt mit einer Auth-Anfrage
  2. Ein Login-REST-API alle solche Anfragen
    3. Griff
  3. Es dauert in Auth Parameter (API-Schlüssel, uid / PWD oder was auch immer Sie wählen) und überprüft Auth gegen den Benutzerspeicher (LDAP, AD, oder MySQL DB etc.)
  4. Wenn verifiziert, erstellt eine Auth-Token und übergibt es wieder auf dem Client / Anrufer
  5. Der Anrufer sendet dann dieses auth-Token + Anfrage spezifisches params mit jede nachfolgende Anforderung an anderen Unternehmen REST-APIs, bis abgemeldet oder bis der Mietvertrag ausläuft

Klar, in Way-2, muß der REST-APIs eine Art und Weise des Token als gültig zu erkennen und zu vertrauen. Die Anmeldung API ausgeführt, um die Auth-Verifikation und damit, dass „Dienerschlüssel“ von anderem REST-APIs vertraut werden muss in Ihrem Katalog.

Das ist natürlich bedeutet, dass der Auth-Schlüssel / Token unter dem REST-APIs gespeichert und gemeinsam genutzt werden muß. Diese gemeinsame, vertrauenswürdige Token-Repository können lokale / föderierte sein, was auch immer, so dass REST-APIs von anderen Organisationen, einander zu vertrauen.

Aber ich schweife ab.

Der Punkt ist ein „Zustand“ (über den authentifizierten Status des Clients) muss beibehalten und gemeinsam genutzt werden, so dass alle REST-APIs einen Kreis des Vertrauens schaffen. Wenn wir dies nicht tun, was der Weg-1 ist, müssen wir akzeptieren, dass ein Akt der Authentifizierung für jede / alle Anforderungen ausgeführt werden müssen, kommen in.

Authentifizierung ist ein ressourcenintensiver Prozess. Stellen Sie sich vor SQL-Abfragen ausgeführt wird, für jede eingehende Anforderung, gegen Ihren Benutzerspeicher für uid / PWD Spiel zu überprüfen. Oder zum Verschlüsseln und Hash-Matches (der AWS-Stil) durchführen. und architecturally wird jeder REST API dies ausführen muß, wie ich vermute, einen gemeinsamen Back-End-Login-Dienst. Denn wenn Sie dies nicht tun, dann sind Sie verunreinigen den Auth-Code überall. Ein großes Durcheinander.

So mehr die Schichten, mehr Latenz.

Nun, nehmen Way-1 und HTM anzuwenden. Hat Sie (Mensch) Benutzer wirklich egal, ob Sie uid / PWD / hash oder was auch immer bei jeder Anfrage senden? Nein, solange Sie nicht die Mühe, sie durch das Werfen Auth / Login-Seite jede Sekunde. Viel Glück mit Kunden, wenn Sie tun. Also, was Sie tun, ist die Login-Informationen irgendwo auf der Clientseite zu speichern, im Browser, gleich am Anfang, und senden Sie es mit jeder Anfrage gemacht. Für die (menschlichen) Benutzer hat sie bereits angemeldet, und eine „Sitzung“ zur Verfügung. Aber in Wirklichkeit ist sie auf jede Anforderung authentifiziert.

Samt mit Way-2. Ihre (human) Benutzer nie bemerken. So wurde nicht geschadet.

Was passiert, wenn wir Way-1 bis MTM bewerben? In diesem Fall, da seine Maschine können wir trugen die Hölle aus diesem Mann, indem er ihnen Authentifizierungsinformationen mit jedem Antrag stellen. Niemanden interessierts! Performing Way-2 auf MTM wird keine besondere Reaktion hervorrufen; es ist eine verdammte Maschine. Es könnte wurscht!

Also wirklich, die Frage ist, was Ihren Bedarf passt. Staatenlosigkeit hat einen Preis zu zahlen. Zahlen den Preis und bewegen. Wenn Sie möchten, ein Purist sein, dann zahlt den Preis für das auch, und zieht weiter.

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

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 auf alle Server.

  3. Wenn ein Client authentifiziert:

    3.1. Ausgabe ein Token, das die folgende enthält:

    • Ablaufzeit
    • Benutzer Name (optional)
    • Benutzer IP (optional)
    • Hash eines Passwortes (optional)

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

    3.3. Senden Sie die verschlüsselten Token zurück an den Benutzer.

  4. Wenn der Benutzer eine beliebige API zugreift, muss sie auch in ihrem Auth-Token übergeben.

  5. können Server überprüfen, ob das Token durch Entschlüsseln gültig ist der Auth-Server den öffentlichen Schlüssel verwenden.

Dies ist staatenlos / RESTful Authentifizierung.

Beachten Sie, dass, wenn ein Passwort-Hash des Benutzer enthalten war auch das unverschlüsselte Passwort zusammen mit den Authentifizierungs-Token senden würde. Der Server konnte überprüfen, ob das Passwort das Passwort angepasst, das verwendet wurde durch den Vergleich Hashes die Authentifizierungs-Token zu erstellen. Eine sichere Verbindung so etwas wie HTTPS verwenden wäre notwendig. Javascript auf der Clientseite umgehen konnte das Kennwort des Benutzers erhalten und Client-Seite, entweder im internen Speicher oder in einem Cookie, möglicherweise verschlüsselte mit dem Server des Öffentlichkeit Schlüsseln zu speichern.

Um ehrlich zu sein mit dir, ich habe hier tolle Antworten gesehen, aber etwas, das mich stört, ein bisschen ist, wenn jemand das ganze Stateless Konzept auf einen extremen nehmen wird, wo es dogmatisch wird. Es erinnert mich an die alten Smalltalk Fans, die nur reine OO umarmen wollte, und wenn etwas nicht ein Objekt ist, dann bist du es falsch zu machen. Gib mir eine Pause.

Der RESTful Ansatz soll Ihnen das Leben leichter und reduzieren den Aufwand und die Kosten der Sitzungen machen, versuchen Sie es zu folgen, wie es eine kluge Sache zu tun, aber in dem Moment folgen Sie eine Disziplin (jede Disziplin / Richtlinie) auf die extrem, wo es nicht mehr den Vorteil bietet es bestimmt war, dann bist du es falsch zu machen. Einige der besten Sprachen heute haben beide, die funktionale Programmierung und Objektorientierung.

Wenn der einfachste Weg für Sie, Ihr Problem zu lösen, ist den Authentifizierungsschlüssel in einem Cookie zu speichern und auf HTTP-Header senden, dann tun, missbrauchen einfach nicht. Denken Sie daran, dass Sitzungen schlecht sind, wenn sie schwer und groß werden, wenn alle Ihre Sitzung besteht aus einer kurzen Zeichenfolge, die einen Schlüssel enthält, was ist dann das Problem?

Ich bin offen Korrekturen in den Kommentaren zu akzeptieren, aber ich sehe nicht, den Punkt (bisher) unser Leben elend einfach bei der Herstellung zu vermeiden, ein großes Wörterbuch von Hashes in unserem Server zu halten.

In erster Linie ein RESTful Web-Service ist STATELESS (oder in anderen Worten: zu ). Daher hat ein RESTful-Dienst nicht und sollte nicht ein Konzept der Sitzung oder Cookies beteiligt haben. Die Art und Weise Authentifizierung oder Autorisierung in dem RESTful-Dienst zu tun ist durch den HTTP-Authorization-Header, wie in den RFC 2616 HTTP-Spezifikationen definiert. Jede einzelne Anforderung sollte den HTTP-Authorization-Header enthalten, und die Anforderung sollte über eine HTTPS-Verbindung (SSL) gesendet werden. Dies ist der richtige Weg, die Authentifizierung zu tun, und die Autorisierung von Anfragen in einem HTTP RESTful Web-Service zu überprüfen. Ich habe einen RESTful Web-Service für die Cisco PRIME Performance Manager Anwendung bei Cisco Systems implementiert. Und als Teil dieses Web-Service, habe ich implementiert Authentifizierung / Autorisierung als auch.

Rubens Gomes.

Es ist sicherlich nicht über „Sitzungsschlüssel“, wie es im Allgemeinen Authentifizierung sitzungs Bezug zu nehmen, die in allen von den Zwängen der REST durchgeführt wird. Jede Anfrage ist selbsterklärend, genug Information trägt den Antrag auf seine eigene ohne serverseitige Anwendung Zustand zu autorisieren.

Der einfachste Weg, um diesen Ansatz ist, indem sie mit HTTP-internen Authentifizierungsmechanismen im RFC 2617 beginnen .

Die 'sehr aufschlussreich' Artikel von @skrebel erwähnt ( http://www.berenddeboer.net /rest/authentication.html ) bespricht eine gewundene aber wirklich gebrochene Methode der Authentifizierung.

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

(Leider kann ich nicht auf die Antwort kommentieren.)

würde ich sagen, REST und Authentifizierung einfach nicht mischen. REST bedeutet staatenlos, sondern ‚authentifiziert‘ ist ein Zustand. Sie können haben sie nicht beide in der gleichen Schicht. Wenn Sie einen RESTful Anwalt und missbilligen Staaten sind, dann müssen Sie mit HTTPS gehen (das heißt die Sicherheitslücke verlassen, um eine andere Schicht).

Ich denke, erholsame Authentifizierung die Übergabe einer Authentifizierungs-Token als Parameter in der Anforderung umfasst. Beispiele sind die Verwendung von apikeys von api. Ich glaube nicht, die Verwendung von Cookies oder HTTP Auth qualifiziert.

Update auf 16-Feb-2019

Der Ansatz früher unten erwähnt ist im Wesentlichen "Ressourcen Owner Passwort Credential" grant Art von OAuth2.0 . Dies ist eine einfache Möglichkeit, aufstehen und laufen. Mit diesem Ansatz wird jedoch jede Anwendung in der Organisation mit eigenen Authentifizierungs- und Autorisierungsmechanismen enden. Der empfohlene Ansatz ist „Berechtigungscode“ grant Typ. Zusätzlich unten in meiner früheren Antwort habe ich empfohlen Browser localstorage für Token Auth zu speichern. Allerdings bin ich gekommen, dass Cookie zu glauben, die richtige Wahl für diesen Zweck ist. Ich habe meine Gründe detailliert, Autorisierungscode Implementierungsansatz Erteilung Art, Sicherheitsaspekte usw. in diese Stackoverflow beantworten .

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

  1. Erstellen Sie einen Login RESTful API-Benutzernamen und das Passwort für die Authentifizierung zu akzeptieren. Verwenden Sie HTTP-POST-Methode zu verhindern, Caching und SSL für die Sicherheit während des Transports Bei erfolgreicher Authentifizierung, gibt die API zwei JWTs - ein Zugriffstoken (kürzere Gültigkeit, etwa 30 Minuten) und eine Aktualisierungs-Token (längere Gültigkeit, sagen 24 h)
  2. Der Client (eine Web-basierte UI) speichert die JWTs in lokalen Speichern und in jedem folgenden API-Aufruf übergibt die Zugriffstoken in "Authorization: Inhaber #access Token" Header
  3. Die API überprüft die Gültigkeit des Tokens durch die Unterschrift und das Ablaufdatum zu überprüfen. Wenn das Token gültig ist, zu prüfen, ob der Benutzer (Es interpretiert den „sub“ in Anspruch JWT als Benutzername) Zugriff auf die API mit einem Cache-Lookup hat. Wenn der Benutzer autorisiert ist, die API für den Zugriff auf, führen Sie die Business-Logik
  4. Wenn das Token abgelaufen ist, kehrt die API HTTP-Antwortcode 400
  5. Der Client, auf 400/401 empfängt, ruft eine anderen REST-API mit den Aktualisierungs-Token in "Authorization: Inhaber #refresh Token" Header einen neuen Zugriffstoken zu erhalten.
  6. Auf den Anruf mit Aktualisierungs-Token empfangen, überprüfen, ob die Aktualisierungs-Token durch Überprüfen der Unterschrift und das Ablaufdatum gültig ist. Wenn die Aktualisierungs-Token gültig sind, aktualisieren Sie die Zugriffsrecht-Cache des Benutzers von DB und neue Zugriffstoken zurückgeben und aktualisieren Token. Wenn die Aktualisierungs-Token ungültig sind, zurückkehrt HTTP-Antwortcode 400
  7. Wenn ein neues Zugriffstoken und Aktualisierungs-Token zurückgegeben werden, gehen Sie zu Schritt 2. Wenn HTTP-Antwortcode 400 zurückgegeben wird, nimmt der Kunde, dass die Aktualisierungs-Token sind abgelaufen und fragt nach Benutzername und Passwort von dem Benutzer
  8. Für logout, spült die lokale Speicherung

Mit diesem Ansatz, den wir tun, um die teure Operation des Cache mit benutzerspezifischen Zugriff Laden rechts alle 30 Minuten Details. Also, wenn ein Zugriff auf Widerruf oder ein neuer Zugang gewährt wird, es dauert 30 Minuten durch einen Login zu reflektieren oder eine Abmelde gefolgt.

Das ist der Weg das zu tun: Mit OAuth 2.0 für Anmeldung .

Sie andere Authentifizierungsmethoden verwenden, können andere dann Googles solange es OAuth unterstützt.

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

Ein Authentifizierungssystem, das REST verwendet, so dass Sie eigentlich nicht die Benutzer in Ihrem System verfolgen müssen oder verwalten. Dies wird durch die Verwendung der HTTP-Methoden POST, GET, PUT, DELETE getan. Wir nehmen diese vier Methoden und von ihnen denken, in Bezug auf die Datenbank-Interaktion wie CREATE, READ, UPDATE, DELETE (aber auf dem Netz verwenden wir POST und GET, weil das ist, was Anker-Tags unterstützen derzeit). So POST Behandlung und GET als unsere CREATE / READ / UPDATE / DELETE (CRUD), dann können wir entwerfen Routen in unserer Web-Anwendung, die Lage zu folgern, welche Maßnahmen von CRUD wir erzielen.

Zum Beispiel in einer Ruby on Rails-Anwendung können wir unseren Web-App bauen, so dass, wenn ein Benutzer, die Besuche angemeldet ist

einen öffentlichen Schlüssel infrastruction Verwendung in dem die Eintragung eines Schlüssels richtige Bindung sorgt beinhaltet, dass der öffentliche Schlüssel an die einzelnen gebunden ist, an dem sie in einer Weise zugeordnet, die Nichtabstreitbarkeit gewährleistet

Siehe http://en.wikipedia.org/wiki/Public_key_infrastructure . Wenn Sie die richtigen PKI-Standards, die Person oder Agenten folgen, die nicht ordnungsgemäß die gestohlenen Schlüssel verwenden, kann identifiziert und gesperrt werden. Wenn der Agent erforderlich ist, um ein Zertifikat zu verwenden, wird die Bindung ziemlich eng. Ein kluger und schnell bewegender Dieb kann entkommen, aber sie lassen mehr Krümel.

Tipp gilt für die Sicherung jeder Web-Anwendung

Wenn Sie Ihre Anwendung sichern möchten, dann starten Sie sollten auf jeden Fall mit Hilfe von HTTPS statt HTTP , dies sorgt für eine Schaffung von sicheren Kanal zwischen Ihnen und den Benutzern das wird verhindern schnüffeln die Daten hin & her an die Nutzer gesendet und wird dazu beitragen, die ausgetauschten Daten vertraulich zu behandeln.

Sie JWTs (JSON Web Tokens) RESTful APIs zu sichern verwenden können, dies hat viele Vorteile, wenn auf die serverseitige Sitzungen verglichen, sind die Vorteile vor allem:

1- Mehr skalierbare, wie API-Server nicht Sitzungen für jeden Benutzer pflegen muß (was eine große Belastung sein kann, wenn Sie viele Sitzungen haben)

2- JWTs sind Selbstversorger und die Ansprüche haben, die die Benutzerrolle beispielsweise definieren und was er kann und zum Zeitpunkt erteilt Zugang & Ablaufdatum (nach dem JWT nicht gültig)

3- einfacher über die Last-Balancern zu handhaben und wenn Sie mehr API-Server, da Sie nicht die Sitzungsdaten zu teilen haben noch konfigurieren Server zu routen, die Sitzung zu demselben Server, sobald eine Anforderung mit einem JWT es eine beliebigen Server getroffen authentifiziert und autorisiert kann

4- Weniger Druck auf die DB als auch Sie nicht Sitzungs-ID & Daten für jede Anforderung

ständig speichern und abrufen müssen

5- Die JWTs kann nicht manipuliert werden, wenn Sie einen starken Schlüssel verwenden, um die JWT zu unterschreiben, so dass Sie die Ansprüche im JWT vertrauen können, die mit der Anforderung gesendet wird, ohne dass die Benutzersitzung zu prüfen und ob er autorisiert oder nicht, können Sie einfach die JWT überprüfen und dann werden Sie alle wissen, wer eingestellt und was der Nutzer tun können.

Viele Bibliotheken einfache Möglichkeiten bieten JWTs in den meisten Programmiersprachen, zum Beispiel zu erstellen und zu validieren: in node.js eine der beliebtesten ist jsonwebtoken

Da REST-APIs im Allgemeinen den Server staatenlos halten will, so JWTs mit diesem Konzept mehr kompatibel ist , da jede Anfrage mit Authorization gesendet wird Token, das versteht sich von selbst enthalten (JWT) ohne den Server Spur von Benutzersitzung im Vergleich zu Sitzungen, die den Server Stateful machen zu halten, so dass es den Benutzer & seine Rolle erinnert, es werden jedoch auch Sitzungen weit verbreitet und ihre Vor- haben, die Sie suchen können, wenn Sie wollen.

Eine wichtige Sache zu beachten ist, dass Sie sicher den JWT an den Client liefern über HTTPS und es an einem sicheren Ort (zum Beispiel im lokalen Speicher) speichern.

Sie können mehr über JWTs erfahren von diesem Link

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top