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

Das ist der richtige Weg, um das zu tun: OAuth 2.0 für die Anmeldung verwenden .

Sie können auch andere Authentifizierungsmethoden als die von Google verwenden, solange sie OAuth unterstützen.

Answer 2

Die Verwendung einer Infrastruktur für öffentliche Schlüssel, bei der die Registrierung eines Schlüssels mit einer ordnungsgemäßen Bindung verbunden ist, stellt sicher, dass der öffentliche Schlüssel an die Person gebunden ist, der er zugewiesen wurde, und zwar auf eine Weise, die eine Nichtabstreitbarkeit gewährleistet.

Ver http://en.wikipedia.org/wiki/Public_key_infrastructure . Wenn Sie die entsprechenden PKI-Standards einhalten, kann die Person oder der Beauftragte, die/der den gestohlenen Schlüssel missbräuchlich verwendet, identifiziert und ausgesperrt werden. Wenn der Beauftragte ein Zertifikat verwenden muss, wird die Bindung ziemlich eng. Ein cleverer und flinker Dieb kann entkommen, aber er hinterlässt mehr Krümel.

Answer 3

Tipps, die für die Sicherung jeder Webanwendung gelten

Wenn Sie Ihre Bewerbung absichern wollen, dann sollten Sie auf jeden Fall damit beginnen, HTTPS statt HTTP zu verwenden. Dies gewährleistet einen sicheren Kanal zwischen Ihnen und den Benutzern, der das Abhören der hin- und hergesendeten Daten verhindert und die Vertraulichkeit der ausgetauschten Daten gewährleistet.

Sie können JWTs (JSON Web Tokens) verwenden, um RESTful APIs zu sichern Dies hat viele Vorteile im Vergleich zu serverseitigen Sitzungen, vor allem folgende:

1- bessere Skalierbarkeit, da Ihre API-Server nicht für jeden Benutzer Sitzungen verwalten müssen (was bei vielen Sitzungen eine große Belastung sein kann)

2- JWTs sind in sich geschlossen und haben Ansprüche, die z.B. die Rolle des Benutzers definieren und auf was er zugreifen kann, sowie ein Datum und ein Ablaufdatum (nach dem das JWT nicht mehr gültig ist).

3- Einfachere Handhabung über Load-Balancer hinweg und bei mehreren API-Servern, da Sie weder Sitzungsdaten gemeinsam nutzen noch den Server so konfigurieren müssen, dass er die Sitzung an denselben Server weiterleitet. Sobald eine Anfrage mit einem JWT auf einen beliebigen Server trifft, kann sie authentifiziert und autorisiert werden.

4- Weniger Druck auf Ihre DB, da Sie nicht ständig Sitzungs-ID und Daten für jede Anfrage speichern und abrufen müssen

5- Die JWTs können nicht manipuliert werden, wenn Sie einen starken Schlüssel verwenden, um das JWT zu signieren. So können Sie den Behauptungen im JWT vertrauen, das mit der Anfrage gesendet wird, ohne die Benutzersitzung überprüfen zu müssen und ohne zu wissen, ob er autorisiert ist oder nicht, Sie können einfach das JWT überprüfen und wissen dann, wer und was dieser Benutzer tun kann.

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

Da REST-APIs im Allgemeinen darauf abzielen, den Server zustandslos zu halten, sind JWTs besser mit diesem Konzept vereinbar. da jede Anfrage mit einem Autorisierungs-Token gesendet wird, das in sich geschlossen ist (JWT) ohne dass der Server die Benutzersitzung nachverfolgen muss, im Vergleich zu Sessions, die den Server zu einem zustandsabhängigen System machen, so dass er sich den Benutzer und seine Rolle merkt, allerdings sind Sessions auch weit verbreitet und haben ihre Vorteile, die Sie suchen können, wenn Sie wollen.

Wichtig ist, dass Sie die JWT sicher über HTTPS an den Client übermitteln und an einem sicheren Ort speichern (z. B. im lokalen Speicher).

Sie können mehr über JWTs erfahren über diesen Link

Answer 4

Um diese Frage aus meiner Sicht zu beantworten...

Ein Authentifizierungssystem, das REST verwendet, so dass Sie die Benutzer in Ihrem System nicht tatsächlich verfolgen oder verwalten müssen. Dies geschieht durch die Verwendung der HTTP-Methoden POST, GET, PUT und DELETE. Wir nehmen diese 4 Methoden und stellen sie uns in Bezug auf die Datenbankinteraktion als CREATE, READ, UPDATE, DELETE vor (im Web verwenden wir POST und GET, weil dies die derzeit unterstützten Anker-Tags sind). Wenn wir also POST und GET als CREATE/READ/UPDATE/DELETE (CRUD) betrachten, können wir in unserer Webanwendung Routen entwerfen, die in der Lage sind, abzuleiten, welche CRUD-Aktion wir erreichen.

In einer Ruby on Rails-Anwendung können wir unsere Webanwendung zum Beispiel so aufbauen, dass ein angemeldeter Benutzer, der die http://store.com/account/logout dann kann der GET dieser Seite als Versuch des Benutzers gesehen werden, sich abzumelden. In unserem Rails-Controller würden wir eine Aktion einbauen, die den Benutzer abmeldet und ihn zurück zur Startseite schickt.

Ein GET auf der Anmeldeseite würde ein Formular ergeben. Ein POST auf der Anmeldeseite würde als Anmeldeversuch gewertet werden und die POST-Daten für die Anmeldung verwenden.

Für mich ist es eine Praxis, HTTP-Methoden zu verwenden, die auf ihre Datenbankbedeutung abgebildet sind, und dann ein Authentifizierungssystem aufzubauen, bei dem man keine Sitzungskennungen weitergeben oder Sitzungen verfolgen muss.

Ich lerne immer noch - wenn Sie etwas, was ich gesagt habe, für falsch halten, korrigieren Sie mich bitte, und wenn Sie mehr erfahren, posten Sie es wieder hier. Danke!