Wie sollte ich einen RESTful-Webservice erstellen, um Drittanbieter (z. B. Google, Facebook, Twitter) für die Authentifizierung zu verwenden?

Für meinen Job haben wir einen netten RESTful-Webservice, den wir ausgebaut haben, um ein paar Websites zu betreiben, die wir haben. Grundsätzlich können Sie mit dem Webservice Support-Tickets erstellen und bearbeiten, und die Website ist für das Front-End verantwortlich. Alle Webservice-Anfragen verwenden einen Auth-Header, mit dem wir den Benutzer und sein Kennwort für jeden Anruf validieren.

In diesem Jahr möchten wir unsere Anmeldemöglichkeiten erweitern, damit sich Benutzer auf der Website über Google, Twitter und Facebook (möglicherweise auch andere) anmelden können. Ich habe jedoch große Probleme, herauszufinden, wie ich dies gestalten soll, damit der Webservice die Authentifizierungsanbieter von Drittanbietern verwenden kann, um sicherzustellen, dass die Benutzer so sind, wie sie sich ausgeben. Gibt es Best Practices dafür?

Momentan denken wir daran, dass die Website die Authentifizierung der Benutzer selbst durchführt und dann einen neuen Aufruf setSessionId verwendet, der ihre aktuelle Sitzung im Webservice-Back-End registriert. Jede weitere Anfrage an den Webservice leitet diese sessionId weiter und validiert sie. Dies scheint in Ordnung zu sein, aber ich habe das Gefühl im Hinterkopf, dass ich nicht darüber nachdenke und all mein Forum, in dem ich die oauth- und openid-Spezifikationen durchstöbere und lese, verwirrt mich nur noch mehr. Irgendwelche Tipps, wie man das angeht?

Es hört sich so an, als gäbe es zwei Ziele:

1. Endbenutzer können sich problemlos mit ihren vorhandenen sozialen Konten authentifizieren
2. Einfach für Entwickler, die Ihren Webservice nutzen

Die Autorisierung von Personen zur Verwendung von Ressourcen auf Ihrer Site macht OAuth2 aufgrund der Popularität und Verfügbarkeit von Client-Bibliotheken zu einem bevorzugten Mechanismus.

1. Endbenutzer können sich problemlos mit ihren vorhandenen sozialen Konten authentifizieren

Der Endbenutzer besucht eine Site, die Ihre API verwendet, und wählt die Anmeldung aus. Sie werden an Ihre OAuth-Anmeldeseite gesendet. Auf Ihrer Anmeldeseite werden ein normaler Benutzername und ein Kennwort für die auf Ihrer Website verwalteten Konten sowie eine Reihe von sozialen Authentifizierungsschaltflächen angezeigt, auf die Sie klicken können, um sich über eine Website wie Facebook anzumelden. Wenn der Benutzer Facebook auswählt, leiten Sie ihn zu Facebook weiter, um die Auswahl zu bestätigen (Starten des Facebook-Authentifizierungsflusses). Wenn der Endbenutzer die Anmeldung bei Facebook abgeschlossen hat, wird er zu Ihrer Website zurückgeleitet.

Wenn der Benutzer von Facebook auf Ihre Website zurückgeleitet wird, speichern Sie die Informationen dieses Benutzers in einem Benutzerdatensatz in Ihrer Datenbank und generieren dann eine neue Sitzung für diesen Benutzer. Sie leiten den Endbenutzer sofort mit dem oauth access_token zu seiner ursprünglichen Downstream-Site weiter und vervollständigen so den ursprünglichen oauth-Flow.

2. Einfach für Entwickler, die Ihren Webservice nutzen

Wenn Sie der Autorisierungsanbieter sind, sollten Sie eine einfache Schnittstelle erstellen, von der Entwickler abhängen können, die sich nicht jedes Mal ändert, wenn Sie einen neuen Upstream-Authentifizierungsanbieter hinzufügen, der nicht perfekt implementiert ist. Aus diesem Grund sollten Sie meiner Meinung nach eine OAuth2-Anbietersite implementieren und diese Site sollte ein Konsument der Websites für soziale Authentifizierungen sein.

Dem Entwickler, der Ihre nette Ruhe-API verwendet, wird die Facebook-Interaktion nur dann bekannt sein, wenn Sie ihm einen Hinweis über den Sitzungserfassungsbeitrag geben (zum Beispiel).

TL; DR

Machen Sie Benutzer Ihrer APIs wie Sie, indem Sie OAuth2 implementieren und die Komplexität der sozialen Authentifizierung verbergen. Sie können während Ihres Oauth-Flows für Ihre Downstream-Sites einen zusätzlichen Oauth-Flow mit Facebook auslösen.

Bild weil Bild == Worte * 1000:

Können wir das oauth2-piggy-back nennen?

Schritt für Schritt fließen

1. Der Endbenutzer besucht die Website, die Ihre API verwendet
2. Der Endbenutzer wird zur Autorisierung oder Registrierung auf Ihre Website weitergeleitet (oauth2).
3. Der Endbenutzer wählt die soziale Authentifizierung und klickt auf die Facebook-Anmeldeschaltfläche
4. Ihre Site setzt ein Cookie oder setzt das statein Facebook, um zu wissen, woher der Benutzer kam
5. Der Endbenutzer wird zu Facebook weitergeleitet und akzeptiert die Verbindung auf der Facebook-Website
6. Der Endbenutzer wird auf Ihre Website umgeleitet, um den Facebook-Authentifizierungsprozess abzuschließen
7. Sie suchen oder erstellen den Benutzer in Ihrer Datenbank
8. Sie erstellen eine neue Sitzung auf Ihrem Server
9. Sie leiten den Benutzer mit Ihrem Sitzungstoken zurück zu seiner ursprünglichen Site

Wie man es erweiterbar macht

Zunächst sollten Sie feststellen, dass alle diese APIs denselben Anmeldemechanismus verwenden. Sie alle verwenden OAuth für ihre Authentifizierung. Dies müssen Sie nutzen, indem Sie mit einer allgemeinen OAuth-Bibliothek beginnen. Verwenden Sie keine eigenen Bibliotheken zur Authentifizierung, da diese für andere Anbieter unbrauchbar werden. Wenn Sie OAuth2 kennen, können Sie ganz einfach weitere Anbieter hinzufügen.

Du brauchst leider zwei davon, denn Twitter hat den OAuth2-Zug noch nicht gesprungen.

In OAuth müssen Sie eine Schnittstelle für die authentifizierende Partei erstellen. Die Token werden Server für Server ausgetauscht. Erstellen Sie einen Einstiegspunkt, der für die gesamte Kommunikation zuständig ist.

Das Token sollte in einer separaten Tabelle von Ihrem Konto gespeichert werden. Dies liegt daran, dass es sich um mehrere Token und mehrere verknüpfte Profile handeln kann. Bei einigen Diensten erhalten Sie zwei Token, von denen einer ein Aktualisierungstoken ist.

Jetzt entwerfen Sie eine Schnittstelle, die die anderen Funktionen enthält, die Sie benötigen. Ich würde dafür persönlich einen eigenen REST-Service einrichten. Auf diese Weise können Sie die Authentifizierung problemlos auf andere Bereiche ausweiten.
Einige Dienste verwenden JSON für die Kommunikation, andere setzen auf XML usw. Für den Front-User müssen Sie sie alle vereinheitlichen. Dies ist ein ziemlich schmerzhafter Prozess, aber es ist möglich, hier einige Gemeinsamkeiten abzuleiten.

Ein weiteres Problem ist, dass nicht alle Dienste dieselbe Funktionalität bieten. Dies kann bedeuten, dass Ihre Dienste nicht die von Ihnen angegebene vollständige API bereitstellen können. Hier muss eine Strategie vorhanden sein, mit der die Anwendung ordnungsgemäß heruntergestuft werden kann.

Auf diese Weise können Sie problemlos neue Drittanbieter hinzufügen.

Token-Probleme

Die Token sind zeitlich begrenzt, daher benötigen Sie einige Cron-Jobs, mit denen überprüft werden kann, ob das Token noch verwendet werden kann. Andernfalls müssen Sie es löschen. Mit diesem Mechanismus können Sie auch ein Token aktualisieren.

Es kommt manchmal vor, dass ein Benutzer das Token zurückzieht. Sei bereit dafür.

Datenspeicher

Wenn Sie dieses Design haben, müssen Sie über die Daten nachdenken, die Sie benötigen. Dies ergibt sich teilweise aus Ihrer gerade erstellten Benutzeroberfläche. Entwerfen Sie hierfür einige Tabellen und prüfen Sie, ob die Daten tatsächlich abrufbar sind. Bei einigen Diensten können Sie nicht viele Daten abrufen. Sie sollten auch berücksichtigen, dass die Datenschutznachrichten umso schwerer werden, je mehr Daten Sie benötigen. Seien Sie also in Ihren Bedürfnissen bescheiden, sonst werden die Benutzer es nicht verwenden.

Zur zusätzlichen Überprüfung können Sie die Profile in einer separaten, aber verknüpften Tabelle für Ihre Benutzer speichern. Dadurch erhalten Sie viel mehr Informationen über jemanden.

Überprüfen Sie auch Ihre lokalen Gesetze, für einige Daten benötigen Sie zusätzliche Vorsichtsmaßnahmen.

Letzte Sache Machen Sie keinen Fehler, wenn Sie kein Konto für Ihre eigenen Dienste erstellen. Wenn der Benutzer von Facebook gebannt wird, kann er sich nicht mehr bei Ihrem Dienst anmelden. Dies ist eine Situation, die Sie nicht erstellen möchten. Dies wird oft übersehen.

Ich würde definitiv mit der Lösung weitermachen, wie es sich anhört, als hätten Sie es bereits herausgefunden: Implementieren der Authentifizierung von Drittanbietern auf Ihrer Client-bezogenen Website und Verknüpfen dieser Authentifizierungstoken von Drittanbietern mit Ihren Website-Benutzerkonten und Auslösen Ihres setSessionID-Aufrufs auf Anmeldung.

Abhängig von Ihrer Website-Architektur kann es hilfreich sein , eine Bibliothek wie EveryAuth oder Passport zu verwenden.

Meine zwei Cent: Ich habe noch nie so etwas gemacht und weiß auch nicht, wie die Anmeldemechanismen von FB, Twitter oder Google funktionieren, aber ein paar Probleme tauchten in meinem Kopf auf, sobald ich Ihre Frage gelesen habe:

• Mehrere Anmeldungen: Was passiert, wenn ich mich an einem Tag mit meinem Facebook-Konto und am nächsten mit meinem Google-Konto anmelde? Oder gleichzeitig? Behandeln Sie diese beiden Konten als eindeutige, separate Konten, oder sollten Sie eine Methode haben, um die beiden Konten zuzuordnen und mir den Zugriff auf meine Tickets zu ermöglichen?
• Auf externe Identifikatoren setzen: Was passiert, wenn Facebook oder Twitter das Erscheinungsbild ihrer Account-Identifikatoren ändern? Um zu veranschaulichen, ob BazLogin ein eindeutiges Konto mit dem Code {4382-af56} darstellt, jedoch feststellt, dass Konten von nun an 12 Ziffern haben, da 8 nicht ausreichen, wie können Sie {1234-4382-af56} von {toget4382} unterscheiden -af56}?

Wir können diese beiden Probleme lösen, indem wir die externen Konten einem internen Konto und nicht nur einer Sitzungs-ID zuordnen. Dann kann ein externes Login nur ein Einstieg in die Erstellung eines internen Kontos sein. Sollte ich mich mit mehr als einer Anmeldemethode authentifizieren, können Sie mir mitteilen, dass ich bereits angemeldet bin. Wenn ein externer Authentifizierungsanbieter etwas ändert, auf das wir uns verlassen, können wir den Benutzer auffordern, den Namen und das Passwort seines internen Kontos anzugeben und eine zu erstellen neue Zuordnung für zukünftige Logins.

Ich bin mir nicht sicher, ob ich die von Ihnen angesprochenen Probleme angesprochen habe, aber Sie haben keine konkreten Bedenken geäußert. Ich hoffe, meine Antwort war in beiden Fällen hilfreich.