it-swarm.com.de

REST API Login Pattern

Ich erstelle eine REST -API, die den Vorschlägen für Apigees genau folgt, wobei ich Substantive und keine Verben verwende, die in die URL eingebrannte API-Version, zwei API-Pfade pro Sammlung, die Verwendung von GET POST PUT DELETE usw.

Ich arbeite am Anmeldesystem, bin mir jedoch nicht sicher, wie ich Benutzer richtig REST anmelden kann. Ich arbeite an dieser Stelle nicht an der Sicherheit, sondern nur am Anmeldemuster oder -fluss. (Später werden wir 2 Schritte oAuth mit einem HMAC usw. hinzufügen.)

Möglichkeiten

  • Ein POST auf etwas wie https://api...com/v1/login.json
  • Ein PUT auf etwas wie https://api...com/v1/users.json
  • Sowas habe ich allerdings nicht von ...

Was ist der richtige REST Stil zum Anmelden von Benutzern?

174
Scott Roepnack

Principled Design der modernen Webarchitektur von Roy T. Fielding und Richard N. Taylor , dh Abfolge von Werken aus allen REST Terminologie stammt von, enthält Definition von Client- Serverinteraktion:

Alle REST Interaktionen sind zustandslos . Das heißt, jede Anforderung enthält alle Informationen, die ein Konnektor benötigt, um die Anforderung zu verstehen, unabhängig von den Anforderungen, die ihr vorangegangen sind . .

Diese Einschränkung erfüllt vier Funktionen: 1. und 3. sind in diesem speziellen Fall wichtig:

  • 1st: Es beseitigt die Notwendigkeit, dass die Connectors den Anwendungsstatus zwischen Anforderungen beibehalten, wodurch der Verbrauch von physischen Ressourcen und Ressourcen reduziert wird Verbesserung der Skalierbarkeit;
  • 3rd: Ermöglicht es einem Vermittler, eine Anfrage isoliert anzusehen und zu verstehen , was bei dynamischen Diensten erforderlich sein kann neu angeordnet;

Und jetzt kehren wir zu Ihrem Sicherheitsfall zurück. Jede einzelne Anfrage sollte alle erforderlichen Informationen enthalten, und die Autorisierung/Authentifizierung ist keine Ausnahme. Wie kann man das erreichen? Senden Sie bei jeder Anfrage buchstäblich alle erforderlichen Informationen über Kabel.

Ein Beispiel für die Archivierung ist Hash-basierter Nachrichtenauthentifizierungscode oder [~ # ~ ] hmac [~ # ~] . In der Praxis bedeutet dies, dass jeder Anforderung ein Hashcode der aktuellen Nachricht hinzugefügt wird. Hash-Code berechnet durch kryptografische Hash-Funktion in Kombination mit einem geheimen kryptografischen Schlüssel. Kryptografische Hash-Funktion ist entweder vordefiniert oder Teil von Code-on-Demand REST Konzeption (zum Beispiel JavaScript). = Geheimer kryptografischer Schlüssel sollte vom Server dem Client als Ressource zur Verfügung gestellt werden, und der Client berechnet daraus den Hash-Code für jede Anforderung.

Es gibt viele Beispiele für [~ # ~] hmac [~ # ~] -Implementierungen, aber ich möchte Sie bitten, auf Folgendes zu achten drei:

Wie es in der Praxis funktioniert

Wenn der Client den geheimen Schlüssel kennt, kann er mit Ressourcen arbeiten. Andernfalls wird er vorübergehend umgeleitet (Statuscode 307 Temporäre Umleitung), um den geheimen Schlüssel zu autorisieren und abzurufen. Anschließend wird er zur ursprünglichen Ressource zurückgeleitet. In diesem Fall gibt es keine Notwendigkeit, vorher zu wissen (d. H. Irgendwo fest zu codieren), wie die URL ist, um den Client zu autorisieren, und es ist möglich, dieses Schema mit der Zeit anzupassen.

Ich hoffe, dies wird Ihnen helfen, die richtige Lösung zu finden!

131
Akim

TL; DR Die Anmeldung für jede Anforderung ist keine erforderliche Komponente, um die API-Sicherheit zu implementieren. Die Authentifizierung erfolgt.

Es ist schwierig, Ihre Frage zum Login zu beantworten, ohne allgemein über Sicherheit zu sprechen. Bei einigen Authentifizierungsschemata gibt es keine herkömmliche Anmeldung.

REST schreibt keine Sicherheitsregeln vor, aber die gängigste Implementierung in der Praxis ist OAuth mit 3-Wege-Authentifizierung (wie Sie in Ihrer Frage erwähnt haben). Es gibt keine Anmeldung per se Zumindest nicht bei jeder API-Anforderung. Bei der 3-Wege-Authentifizierung verwenden Sie nur Token.

  1. Der Benutzer genehmigt den API-Client und erteilt die Berechtigung, Anforderungen in Form eines langlebigen Tokens zu stellen
  2. Ein API-Client erhält ein kurzlebiges Token, indem er das langlebige verwendet.
  3. Der API-Client sendet das kurzlebige Token mit jeder Anforderung.

Dieses Schema gibt dem Benutzer die Möglichkeit, den Zugriff jederzeit zu widerrufen. Praktisch alle öffentlich verfügbaren RESTful-APIs, die ich gesehen habe, verwenden OAuth), um dies zu implementieren.

Ich denke einfach nicht, dass Sie Ihr Problem (und Ihre Frage) in Bezug auf die Anmeldung einrahmen sollten, sondern überlegen, die API im Allgemeinen zu sichern.

Weitere Informationen zur Authentifizierung von REST APIs im Allgemeinen finden Sie in den folgenden Ressourcen:

41
Slavo

Ein großer Teil der REST Philosophie besteht darin, beim Entwerfen Ihrer API so viele Standardfunktionen des HTTP-Protokolls wie möglich zu nutzen. Bei Anwendung dieser Philosophie auf Authentifizierung würden Client und Server die Standardfunktionen der HTTP-Authentifizierung in verwenden die API.

Anmeldebildschirme eignen sich hervorragend für Benutzeranwendungen: Besuchen Sie einen Anmeldebildschirm, geben Sie Benutzer/Kennwort ein, setzen Sie ein Cookie, und der Client stellt dieses Cookie für alle zukünftigen Anforderungen bereit. Es ist nicht zu erwarten, dass Menschen, die Webbrowser verwenden, bei jeder einzelnen HTTP-Anforderung eine Benutzer-ID und ein Kennwort angeben.

Für eine REST API sind ein Anmeldebildschirm und Sitzungscookies nicht unbedingt erforderlich, da jede Anforderung Anmeldeinformationen enthalten kann, ohne dass sich dies auf einen menschlichen Benutzer auswirkt 401 Es kann eine "nicht autorisierte" Antwort gegeben werden. RFC 2617 beschreibt die Authentifizierungsunterstützung in HTTP.

TLS (HTTPS) ist ebenfalls eine Option und ermöglicht die Authentifizierung des Clients gegenüber dem Server (und umgekehrt) bei jeder Anforderung durch Überprüfen des öffentlichen Schlüssels der anderen Partei. Zusätzlich sichert dies den Kanal für einen Bonus. Dazu ist natürlich ein Schlüsselpaaraustausch vor der Kommunikation erforderlich. (Beachten Sie, dass es hier speziell um das Identifizieren/Authentifizieren des Benutzers mit TLS geht. Das Sichern des Kanals mithilfe von TLS/Diffie-Hellman ist immer eine gute Idee, auch wenn Sie den Benutzer nicht anhand seines öffentlichen Schlüssels identifizieren.)

Ein Beispiel: Angenommen, ein OAuth Token ist Ihre vollständigen Anmeldeinformationen. Sobald der Client über das OAuth Token verfügt, könnte es standardmäßig als Benutzer-ID bereitgestellt werden HTTP-Authentifizierung bei jeder Anforderung: Der Server kann das Token bei der ersten Verwendung überprüfen und das Ergebnis der Überprüfung mit einer Lebensdauer zwischenspeichern, die bei jeder Anforderung erneuert wird. Jede Anforderung, die eine Authentifizierung erfordert, gibt 401 Zurück, wenn sie nicht bereitgestellt wird .

24
wberry