Design für die Facebook-Authentifizierung in einer iOS-App, die auch auf einen gesicherten Webdienst zugreift

Question

Ziel: Ermöglichen Sie einem Benutzer die Authentifizierung mit Facebook in eine iOS-Anwendung, die Zugriff auf einen geschützten Webservice erfordert, den ich betreibe.

Annahmen: Es gibt ein natives Authentifizierungs- (und Registrierungs-)System für diejenigen Benutzer, die sich entscheiden, Facebook nicht für die Anmeldung zu verwenden.

Details:

• Annehmen, dass wir dem Benutzer die Möglichkeit bieten möchten, sich mit Facebook anzumelden, ohne ein separates Konto/Anmeldeinformationen für unser System zu erstellen.
• Weil wir unseren eigenen nativen Authentifizierungsmechanismus (Benutzername und Passwort) unterstützen, haben wir unsere eigenen Benutzer-IDs und geben ein Authentifizierungstoken aus, das für nachfolgende Interaktionen nach der anfänglichen Überprüfung der Anmeldeinformationen verwendet wird.

Ich bin überrascht, dass Facebook keine bewährten Verfahren hierfür in ihrer Entwicklerdokumentation hat. Alle vorhandenen Dokumentationen gehen entweder davon aus, dass Sie die FB-Authentifizierung in eine Website integrieren oder eine eigenständige mobile App ohne Dienst erstellen, der eine Authentifizierung erfordert.

Hier sind meine ersten Gedanken dazu, wie dies gestaltet werden könnte, aber ich möchte überprüfen lassen, ob es korrekt ist.

1. Der Client öffnet das Facebook iOS-Login.

2. Der Benutzer meldet sich mit Facebook-Anmeldeinformationen an und erhält Zugriffstoken.

3. Die iOS-App übergibt das Zugriffstoken an unseren Server.

4. Unser Server spricht mit der FB Graph API unter Verwendung des Zugriffstokens, um (a) das Token zu validieren und (b) die FB-Benutzer-ID für dieses Zugriffstoken zu erhalten.

   Zum Beispiel würde unser Server https://graph.facebook.com/me/?access_token=XYZ aufrufen, das Profilinformationen in einem JSON-Objekt zurückgeben würde

5. Wenn es gültig ist, extrahiert unser Server die Benutzer-ID aus dem JSON-Objekt und überprüft, ob der Benutzer bereits ein Konto hat. Falls ja, geben wir unserem Client ein eigenes Authentifizierungsticket für diese Sitzung aus. Wenn der Benutzer kein Konto hat, erstellen wir ein neues Konto mit der Facebook-Benutzer-ID, weisen unsere eigene eindeutige Benutzer-ID zu und geben unser Authentifizierungsticket aus.

6. Der Client übergibt dann das Authentifizierungsticket bei nachfolgenden Interaktionen, die eine Authentifizierung erfordern.

Dies scheint mir der richtige Ansatz zu sein, aber ich bin mir nicht sicher, ob ich etwas unglaublich Grundlegendes übersehe und auf dem falschen (komplizierten) Weg bin.

Answer 1

Ich habe genau damit zu tun gehabt, und hier ist der Teil, der mich verwirrt hat:

In Ihrem Schritt 5... ist es möglich, dass ein Benutzer sich bei Ihnen für ein Konto registriert, das völlig unabhängig von seiner Facebook-ID ist, richtig? Dann melden sie sich irgendwann mit Facebook an.... Und Sie haben einfach ein zweites Konto für sie erstellt und ihr erstes verloren.

Es muss eine Möglichkeit geben, bei Ihrem Webservice angemeldet zu sein, sich dann bei Facebook anzumelden und die Verbindung zwischen der Facebook-ID und dem lokalen Konto zu erfassen.

Abgesehen davon klingt Ihr Plan solide.

Update: Facebook hat eine Dokumentation zu einem solchen Szenario hinzugefügt HIER

Answer 2

Verwenden Sie https, um das Authentifizierungstoken an Ihren Server zu übertragen, wie von Facebook angegeben

Sharing von Zugriffstoken

Unsere Datenschutzrichtlinien verbieten ausdrücklich das Teilen eines Zugriffstokens für Ihre App mit einer anderen App. Wir erlauben jedoch Entwicklern, Tokens zwischen einer nativen Implementierung und einer Serverimplementierung derselben App zu teilen (d. h. unter Verwendung derselben App-ID), solange der Transfer über HTTPS erfolgt.

Answer 3

Ein Problem, das ich bei dieser Strategie sehe, ist, dass jemand Ihnen einen Zugriffstoken für eine andere Facebook-App geben kann. Soweit ich weiß, gibt es keine Möglichkeit zu überprüfen, ob der Zugriffstoken für Ihre Anwendung ist, also werden Sie einfach weitermachen und ihn verwenden.

Es klingt jedoch nicht sehr schädlich. Im Allgemeinen versuchen Menschen / Apps, die Zugriffstoken zu schützen, anstatt sie zu teilen.

Ein mögliches Ausnutzen davon wäre, dass jemand ihre eigene Website oder mobile App erstellt, Zugriffstoken für ihre Benutzer erhält und versucht, diese zu authentifizieren, indem sie Ihre API verwendet. Wenn dies gelingt (der Benutzer hat ein Facebook-Konto auf Ihrer Website), wird die bösartige Website in der Lage sein, Ihre API unter Benutzervorwand zu verwenden.

Es ist ein wenig weit hergeholt, aber ich denke, es könnte funktionieren.

Bearbeitung: Es scheint jedoch eine Möglichkeit zu geben, den Zugriffstoken letztendlich zu validieren. Sehen Sie die Antwort von @Daaniel auf die Frage Holen Sie sich die Anwendungs-ID aus dem Benutzerzugriffstoken (oder überprüfen Sie die Quellanwendung für einen Token).

Answer 4

Deine Lösung funktioniert total.

Vielleicht eine Alternative: Warum nicht einfach die E-Mail auf dem Client aus dem initialen sozialen Dienst-Anfrage bekommen und an deinen Web-Service senden? Der Web-Service könnte einfach die E-Mail speichern, und vielleicht auch den sozialen Anbieter. Ich verstehe, dass dein Web-Service nicht überprüfen kann, woher die E-Mail stammt, aber gibt es nicht eine hohe Vertrauensbeziehung zwischen deinem Web-Service und deinem Client? Wenn ja, scheint es, als ob du darauf vertrauen kannst, dass die E-Mail aus der richtigen Quelle kommt. Bitte lasst mich wissen, was ich offensichtliches übersehe, das den E-Mail-basierten Ansatz albern macht...