REST API Login-Ansatz

8

Wir erstellen ein System, das Anmeldeinformationen für alle Seiten benötigt. Die Anwendung wurde entwickelt, um Restful-Anwendung mit Codeigniter als Phil Sturgeon -Bibliothek. Diese Bibliothek verwendet API-Schlüssel nur, um API-Aufrufe zu autorisieren, indem sie mit jeder Anfrage über eine HTTPS-Verbindung gesendet werden.

Auch wenn es eine 2-Wege-Authentifizierung oder nur einen API-Schlüssel verwendet. Nach was ich suche, ist das folgende Szenario:

  • Benutzer fordern die Anwendung zum ersten Mal an (z. B. Ссылка ), dann wird sie auf die Anmeldeseite weitergeleitet, um die Anmeldedaten zu überprüfen
  • Benutzer geben das Benutzername / Passwort ein und senden es per POST über das https
  • Server überprüft, ob die Informationen gültig sind:

    • API KEY sollte vom Server dem Client als Ressource bereitgestellt werden, die durch diesen Benutzernamen identifiziert wird ( Hier ist die Frage ??? !!! )

    • Wie schicke ich den API-Schlüssel sicher an den Client?

      • 1) Kann ich Session-Cookies verwenden und den API-KEY in einem Cookie wiederherstellen, dann diesen API-KEY bei jeder kommenden Anfrage verwenden (Dies ist brutal der Staatenlose der Ruhe und ich weiß nicht, ob er sicher ist genug).
      • 2) Eigentlich kenne ich keine anderen Optionen :) Sie sind an der Reihe, wenn Sie helfen könnten

Wenn Sie ein Beispiel geben könnten, wäre es eine große Hilfe, da ich viele Artikel gefunden und gelesen habe

:)

    
ahmedsaber111 25.06.2013, 13:05
quelle

1 Antwort

8

Da die Verbindung HTTPS ist, ist alles, was Sie über die Leitung senden, sicher (theoretisch und vorausgesetzt, Sie sind nicht " d). Nicht sicher, ob die gesamte API über HTTPS bedient wird (Sie haben nicht angegeben), also obwohl Sie den Schlüssel als Teil der Anmeldung zurückgeben könnten (während immer noch unter dem Dach von HTTPS), wenn der Rest der API nicht ist HTTPS, könnte der Schlüssel bei der nächsten Anfrage geschnüffelt werden.

Sitzungen und Cookies sind normalerweise nicht Teil einer RESTful-Anwendung. REST ist zustandslos.

Etwas wie ein umlaufender Schlüssel wäre besser für Nicht-HTTPS (würde auch mit HTTPS funktionieren). Sie melden sich über HTTPS an, der Server gibt den API-Schlüssel zurück, Sie verwenden ihn bei der nächsten Anfrage, der Server gibt den neuen API-Schlüssel zurück, Sie verwenden ihn bei der nächsten Anfrage und so weiter. Obwohl es besser ist als ein einzelner API-Schlüssel gegenüber Nicht-HTTPS, ist es nicht perfekt. Wenn jemand die Antwort von einer der nachfolgenden Anfragen schnüffelt und Sie diesen Schlüssel nicht verbrauchen, können Sie ihn verwenden. Dies verkleinert den Angriffsvektor auf eine Nicht-HTTPS-Antwort von Server zu Client, da, wenn eine Anfrage von Client zu Server abgefangen wird, der API-Schlüssel bereits von Ihrer legitimen Anfrage verbraucht wurde. Allerdings sollte mehr getan werden, um die API zu sichern, wenn Sie es nicht über HTTPS bedienen.

Wenn ich es wäre, würde ich in Request signing + https schauen. Es gibt einige Gespräche über die Unterzeichnung von Anträgen hier: Ссылка

Es gibt auch einige Informationen zur Digestauth im Abschnitt Sicherung der API in Ссылка

Ein Pseudocode Beispiel js Funktion auf dem Client

%Vor%

Beispiel Controller-Methode:

%Vor%     
stormdrain 28.06.2013, 18:11
quelle