Frage Wie implementiere ich die Anmeldung in einem REST-fähigen Webdienst?


Ich baue eine Webanwendung mit einer Services-Schicht. Die Services-Schicht wird mit einem RESTful-Design erstellt. Wir sind der Meinung, dass wir in Zukunft möglicherweise andere Anwendungen (iPhone, Android usw.) erstellen werden, die dieselbe Servicesbene wie die Webanwendung verwenden. Meine Frage ist dies - wie implementiere ich Login? Ich glaube, ich habe Schwierigkeiten, von einem traditionelleren verbbasierten Design zu einem ressourcenbasierten Design überzugehen. Wenn ich das mit SOAP erstellen würde, hätte ich wahrscheinlich eine Methode namens Login. In REST sollte ich eine Ressource haben. Ich habe Schwierigkeiten zu verstehen, wie ich meine URI für einen Login erstellen soll. Sollte es in etwa so sein:

http: // meinservice /{Benutzername}? p = {Passwort}

BEARBEITEN: Die Front-End-Webanwendung verwendet das traditionelle ASP.NET-Framework für die Authentifizierung. Irgendwann im Authentifizierungsprozess muss ich die angegebenen Anmeldeinformationen überprüfen. In einer herkömmlichen Webanwendung würde ich eine Datenbanksuche durchführen. Aber in diesem Szenario rufe ich einen Dienst auf, anstatt eine Datenbanksuche durchzuführen. Daher benötige ich etwas im Service, das die angegebenen Anmeldeinformationen überprüft. Zusätzlich zur Validierung der angegebenen Zugangsdaten benötige ich wahrscheinlich auch Informationen über den Benutzer, nachdem er erfolgreich authentifiziert wurde - Dinge wie sein vollständiger Name, seine ID usw. Ich hoffe, dass dies die Frage klarer macht.

Oder denke ich nicht über den richtigen Weg nach? Ich habe das Gefühl, dass ich Schwierigkeiten habe, meine Frage korrekt zu beschreiben.

Corey


76
2018-01-05 19:13


Ursprung


Antworten:


Wie schon S.Lott darauf hingewiesen hat, haben wir hier zwei gefaltete Dinge: Login und Authentifizierung

Die Authentifizierung ist hier nicht möglich, da dies viel diskutiert wird und es Übereinstimmung gibt. Was benötigen wir jedoch für einen Client, um sich erfolgreich gegen einen RESTful-Webdienst zu authentifizieren? Richtig, irgendeine Art von Token, nennen wir es Access-Token.

Client) Also, alles, was ich brauche, ist ein Access-Token, aber wie bekomme ich das REST?
Server) Warum nicht einfach erstellen?
Client) Wie kommt es?
Server) Für mich ist ein Access-Token nichts anderes als eine Ressource. Daher erstelle ich eine für Sie als Gegenleistung für Ihren Benutzernamen und Ihr Passwort.

Daher könnte der Server die Ressourcen-URL "/ accesstokens" anbieten, um den Benutzernamen und das Passwort an die neu erstellte Ressource "/ accesstokens / {accesstoken}" zu senden. Alternativ können Sie ein Dokument mit dem Zugriffstoken und einem href mit dem Link der Ressource zurückgeben:

<Zugriffstoken
  id = "{Zugriffstoken-ID geht hier; beispielsweise GUID}"
  href = "/ accesstokens / {id}"
/>

Höchstwahrscheinlich erstellen Sie das Access-Token nicht als Subresource und fügen daher seine href nicht in die Antwort ein.
Wenn Sie dies jedoch tun, könnte der Client den Link in seinem Namen generieren oder nicht? Nein!
Denken Sie daran, dass REST-konforme Webdienste Ressourcen so miteinander verknüpfen, dass der Client selbst navigieren kann, ohne dass Ressourcenlinks generiert werden müssen.

Die letzte Frage, die Sie wahrscheinlich haben, ist, wenn Sie den Benutzernamen und das Passwort als HTML-Formular oder als ein Dokument, z. XML oder JSON - es kommt darauf an ... :-)


56
2018-01-17 09:55



Sie loggen sich nicht ein. Du "authentifizierst" dich. Welt der Differenz.

Sie haben viele Authentifizierungsalternativen.

HTTP Basic-, Digest-, NTLM- und AWS S3-Authentifizierung

  • HTTP Basic- und Digest-Authentifizierung. Dies verwendet die HTTP_AUTHORIZATION Header. Das ist sehr nett, sehr einfach. Aber kann zu viel Verkehr führen.

  • Benutzername / Signatur Authentifizierung. Wird manchmal "ID and KEY" -Authentifizierung genannt. Dies kann eine Abfragezeichenfolge verwenden.

    ?username=this&signature=some-big-hex-digest 

    Dies ist, was Orte wie Amazon verwenden. Der Benutzername ist die "ID". Der "Schlüssel" ist ein Digest, ähnlich dem für die HTTP-Digest-Authentifizierung. Beide Seiten müssen sich darauf einigen, dass der Digest fortgesetzt wird.

  • Eine Art Cookie-basierte Authentifizierung. OpenAMB. als Agent für die Authentifizierung und Bereitstellung eines Cookies konfiguriert werden, das Ihr REST-fähiger Webserver dann verwenden kann. Der Client würde sich zuerst authentifizieren und dann den Cookie mit jeder RESTful-Anfrage bereitstellen.


23
2018-01-05 19:22



Große Frage, gut gestellt. Ich mag Patricks Antwort sehr. Ich benutze etwas wie

- / Benutzer / {Benutzername} / Login-Sitzung

Mit POST und GET wird behandelt. So poste ich eine neue Login-Sitzung mit den Zugangsdaten und ich kann dann die aktuelle Sitzung als Ressource über das GET anzeigen.

Die Ressource ist eine Anmeldesitzung, die ein Zugriffstoken oder einen Authentifizierungscode, Ablauf usw. haben kann.

Seltsamerweise muss mein MVC-Aufrufer selbst einen Schlüssel / Bearer-Token über einen Header präsentieren, um zu beweisen, dass er das Recht hat, neue Login-Sitzungen zu versuchen und zu erstellen, da die MVC-Site ein Client der API ist.

Bearbeiten

Ich denke, dass einige andere Antworten und Kommentare das Problem mit einem gemeinsamen geheimen Out-of-Band-Problem lösen und nur mit einem Header authentifizieren. In vielen Situationen oder für Service-to-Service-Anrufe ist das kein Problem.

Die andere Lösung besteht darin, ein Token, OAuth oder JWT oder anders zu fließen, was bedeutet, dass die "Anmeldung" bereits durch einen anderen Prozess stattgefunden hat, wahrscheinlich eine normale Login-Benutzeroberfläche in einem Browser, die auf einem Formular POST basiert.

Meine Antwort ist für den Service, der hinter dieser Benutzeroberfläche steht, vorausgesetzt, Sie möchten sich anmelden und die Authentifizierung und Benutzerverwaltung in einem REST-Service und nicht im MVC-Code der Site platzieren. Es ist der Benutzer-Login-Dienst.

Außerdem können andere Dienste sich "anmelden" und ein ablaufendes Token erhalten, anstatt einen vorinstallierten Schlüssel zu verwenden, sowie Testskripts in einer CLI oder einem Post-Manager.


1
2018-06-05 19:35



Seit 2011 hat sich einiges verändert ...

Wenn Sie bereit sind, ein Drittanbieter-Tool zu verwenden und für die Webbenutzeroberfläche geringfügig von REST abzuweichen, sollten Sie darüber nachdenken http://shiro.apache.org.

Shiro gibt Ihnen im Grunde einen Servlet-Filter, der sowohl zur Authentifizierung als auch zur Autorisierung dient. Sie können alle von @ S.Lott aufgelisteten Anmeldeverfahren verwenden, einschließlich einer einfachen formularbasierten Authentifizierung.

Filtern Sie die restlichen URLs, die eine Authentifizierung erfordern, und Shiro erledigt den Rest.

Ich benutze das momentan in meinem eigenen Projekt und es hat bisher sehr gut für mich funktioniert.

Hier ist noch etwas, an dem Leute interessiert sein könnten. https://github.com/PE-INTERNATIONAL/shiro-jersey#readme


0
2018-06-12 15:46



Das erste, was Sie über REST verstehen müssen, ist, dass es sich um einen Token-basierten Ressourcenzugriff handelt. Im Gegensatz zu herkömmlichen Methoden wird der Zugriff basierend auf der Token-Validierung gewährt. In einfachen Worten, wenn Sie ein richtiges Token haben, können Sie auf Ressourcen zugreifen. Jetzt gibt es viele andere Dinge für die Erstellung und Manipulation von Token.

Für Ihre erste Frage können Sie eine Restfull-API entwerfen. Anmeldedaten (Benutzername und Passwort) werden an Ihre Service-Schicht weitergegeben. Die Service-Ebene validiert diese Anmeldedaten und erteilt ein Token. Die Anmeldedaten können entweder ein einfacher Benutzername / Passwort oder SSL-Zertifikate sein. SSL-Zertifikate verwenden das OAUTH-Protokoll und sind sicherer.

Sie können Ihre URI wie folgt gestalten: URI für Token-Anfrage-> http: // myservice / einige-Verzeichnis / Token? (Sie können Credentilals in dieser URI für Token übergeben)

Um dieses Token für den Ressourcenzugriff zu verwenden, können Sie dieses [Authorization: Bearer (Token)] zu Ihrem HTTP-Header hinzufügen.

Dieses Token kann vom Kunden für den Zugriff auf verschiedene Komponenten Ihrer Serviceschicht verwendet werden. Sie können auch den Ablaufzeitraum dieses Tokens ändern, um Missbrauch zu verhindern.

Für Ihre zweite Frage können Sie verschiedene Token für den Zugriff auf verschiedene Ressourcenkomponenten Ihrer Serviceschicht erteilen. Dazu können Sie in Ihrem Token Ressourcenparameter und auf Basis dieses Feldes eine Großberechtigung angeben.

Sie können diesen Links auch folgen, um weitere Informationen zu erhalten. http://www.codeproject.com/Articles/687647/Detailed-Tutorial-for-Building-ASP-NET-WebAPI-REST

http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api


0
2018-02-25 10:06



Ich habe das gleiche Problem schon einmal gesehen. Login kann nicht gut auf Ressourcen-basiertes Design übertragen werden.

Die Art, wie ich normalerweise damit umgehe, ist, dass ich eine Login-Ressource habe und Benutzernamen und Passwort für die Parameter-Zeichenfolge übergebe

Zusteigen, einsteigen, vorwärtskommen http: // myservice / login? u ={Benutzername} & p = {Passwort}

Die Antwort ist eine Art von Sitzung oder Auth-Zeichenfolge, die dann zur Validierung an andere APIs übergeben werden kann.

Eine Alternative zu GET auf der Login-Ressource ist ein POST, REST-Puristen werden mich jetzt wahrscheinlich nicht mögen :) und die Credits im Körper weiterleiten. Die Antwort wäre die gleiche.


-4
2018-01-05 19:18