Verwende für mobile Apps die Facebook-SDKs für iOS und Android, und befolge die jeweiligen Anweisungen für diese Plattformen.
Wenn du jedoch eine Browser-basierte Anmeldung für eine Web- oder Desktop-App ohne unsere SDKs implementieren musst, wie bei einer Web-Ansicht für eine native Desktop-App (z. B. Windows 8) oder einen Login-Vorgang, der ausschließlich serverseitigen Code verwendet, kannst du über Browser-Umleitungen deinen eigenen Login-Vorgang erstellen. In diesem Leitfaden wird jeder einzelne Schritt des Login-Vorgangs und die Implementierung ohne unsere SDKs genau beschrieben:
Um Facebook Login in einer Desktop-App zu verwenden, musst du einen Web-Browser (manchmal auch Web-Ansicht genannt) in die App integrieren, der den Login-Vorgang übernimmt.
Apps, die unsere SDKs verwenden, können mit integrierten Funktionen prüfen, ob sich ein Nutzer bereits angemeldet hat. Alle anderen Apps müssen einen eigenen Weg finden, die Angabe zu speichern, wenn sich ein Nutzer angemeldet hat. Sollte der Indikator nicht vorhanden sein, sollten Apps annehmen, dass der Nutzer abgemeldet ist, und entsprechend fortfahren. Wenn ein Nutzer abgemeldet ist, sollte deine App ihn zum richtigen Zeitpunkt zum Login-Dialog weiterleiten, z. B. wenn er auf den Login-Button klickt.
Egal, ob ein Nutzer, der deine App verwendet, nicht bei deiner App oder bei Facebook angemeldet ist, du kannst ihn über den Login-Dialog dazu auffordern. Wenn ein Nutzer nicht bei Facebook angemeldet ist, wird er aufgefordert, sich dort anzumelden, bevor er sich bei deiner App anmeldet. Dies wird automatisch erkannt, sodass du nichts weiter tun musst.
 |  |
Deine App muss eine Umleitung zu einem Endpunkt starten, an dem der Login-Dialog angezeigt wird:
https://www.facebook.com/v7.0/dialog/oauth?
client_id={app-id}
&redirect_uri={redirect-uri}
&state={state-param}
Für diesen Endpunkt sind die folgenden Parameter erforderlich:
client_id. Die ID deiner App befindet sich in deinem App-Dashboard.redirect_uri. Die URL, zu der du die sich anmeldende Person umleiten möchtest. Diese URL erhält auch die Antwort vom Login-Dialog. Wenn du dies in einer Web-Ansicht innerhalb einer Desktop-App verwendest, musst du dafür https://www.facebook.com/connect/login_success.html festlegen. Im App-Dashboard kannst du bestätigen, dass diese URL für deine App festgelegt ist. Klicke im linken Navigationsmenü des App-Dashboards unter Produkte auf Facebook Login und anschließend auf Einstellungen. Überprüfe die gültigen OAuth Redirect URIs im Abschnitt Client-OAuth-Einstellungen.state. Ein von deiner App erstellter Zeichenfolgenwert, mit dem der Zustand zwischen Anfrage und Rückruf beibehalten wird. Dieser Parameter sollte verwendet werden, um Cross-Site-Request-Forgery-Angriffe zu verhindern, und wird unverändert in deiner Weiterleitungs-URI an dich zurückgegeben.Wenn deine Anfrage beispielsweise wie folgt aussieht:
https://www.facebook.com/v7.0/dialog/oauth?
client_id={app-id}
&redirect_uri={"https://www.domain.com/login"}
&state={"{st=state123abc,ds=123456789}"}
wird deine Weiterleitungs-URI wie folgt aufgerufen:
https://www.domain.com/login?state="{st=state123abc,ds=123456789}"
Außerdem gibt es die folgenden optionalen Parameter:
response_type. Legt fest, ob die Antwortdaten beim Umleiten an die App in URL-Parameter oder URL-Fragmente aufgenommen werden. Weitere Informationen dazu, welchen Typ deine App verwenden sollte, findest du im Abschnitt Bestätigen der Identität. Das kann einer der Folgenden sein:
code. Die Antwortdaten werden als URL-Parameter hinzugefügt und enthalten den code-Parameter (einen verschlüsselten String, der für jede Anmeldeanfrage eindeutig ist). Das ist die Standardeinstellung, falls dieser Parameter nicht angegeben ist. Es ist die sinnvollste Einstellung, wenn dein Server den Schlüssel verwaltet.token. Die Antwortdaten werden als URL-Fragment hinzugefügt und enthalten einen Zugriffsschlüssel. Desktop-Apps müssen diese Einstellung für response_type verwenden. Dies ist die sinnvollste Einstellung, wenn der Client den Schlüssel verwaltet.code%20token. Die Antwortdaten werden als URL-Fragment hinzugefügt und enthalten sowohl einen Zugriffsschlüssel als auch einen code-Parameter.granted_scopes. Gibt eine kommagetrennte Liste aller Berechtigungen zurück, die der Nutzer der App zum Zeitpunkt der Anmeldung gewährt hat. Kann mit anderen response_type-Werten kombiniert werden. Wenn dieser Parameter mit token kombiniert wird, sind die Antwortdaten als URL-Fragment enthalten. Andernfalls sind sie als URL-Parameter enthalten. scope. Eine durch Kommas oder Leerzeichen getrennte Liste von Berechtigungen, die von der Person, die deine App verwendet, angefordert werden.Wenn du einen Anmeldevorgang für eine Windows-App erstellst, kannst du die Paketsicherheitserkennung als deine redirect_uri verwenden. Löse den Login-Dialog aus, indem du WebAuthenticationBroker.AuthenticateAsync aufrufst, und verwende den Login-Dialog-Endpunkt als requestUri. Hier siehst du ein Beispiel in JavaScript:
var requestUri = new Windows.Foundation.Uri(
"https://www.facebook.com/v7.0/dialog/oauth?
client_id={app-id}
&display=popup
&response_type=token
&redirect_uri=ms-app://{package-security-identifier}");
Windows.Security.Authentication.Web.WebAuthenticationBroker.authenticateAsync(
options,
requestUri)
.done(function (result) {
// Handle the response from the Login Dialog
}
);Dadurch wird der Kontrollvorgang zurück an deine App geleitet – mit einem Zugriffsschlüssel bei Erfolg oder einem Fehler bei Misserfolg.
An diesem Punkt im Anmeldevorgang sieht der Nutzer den Login-Dialog. Hier kann er sich entscheiden, ob er die Anmeldung abbrechen oder der App den Zugriff auf seine Daten erlauben möchte.
Wenn die Person, die deine App verwendet, „OK“ im Login-Dialog auswählt, gewährt sie deiner App Zugriff auf ihr öffentliches Profil sowie ihre Freundesliste und akzeptiert alle anderen von deiner App angeforderten Berechtigungen.
In jedem Fall ruft der Browser erneut die App auf, und die Antwortdaten, die angeben, ob sich der Nutzer angemeldet oder die Anmeldung abgebrochen hat, werden an deine App gesendet. Wenn deine App die oben genannte Umleitungsmethode verwendet, enthält die von deiner App zurückgesendete redirect_uri URL-Parameter oder -Fragmente (je nach ausgewähltem response_type), die erfasst werden müssen.
Aufgrund der verschiedenen Kombinationen von Code-Sprachen, die in Web-Apps verwendet werden können, enthält unser Leitfaden keine spezifischen Beispiele. Die meisten modernen Code-Sprachen sind allerdings wie folgt dazu in der Lage, URL-Parsing durchzuführen:
Mit clientseitigem JavaScript können URL-Fragmente erfasst werden (z. B. jQuery BBQ). URL-Parameter können dagegen sowohl mit client- als auch mit serverseitigem Code erfasst werden (z. B. $_GET in PHP, jQuery.deparam in jQuery BBQ, querystring.parse in Node.js oder urlparse in Python). Microsoft stellt dazu einen Leitfaden samt Beispiel-Code für Windows 8-Apps zum Verbinden mit einem Online-Anbieter – in diesem Fall Facebook – zur Verfügung.
Wenn eine Person sich bei einer Desktop-App anmeldet, leitet Facebook sie an die oben genannte redirect_uri um und fügt dem URI-Fragment einen Zugriffsschlüssel sowie einige andere Metadaten (wie die Ablauffrist des Schlüssels) hinzu:
https://www.facebook.com/connect/login_success.html#
access_token=ACCESS_TOKEN...Deine App muss diese Umleitung erkennen und dann den Zugriffsschlüssel mit den vom Betriebssystem und Entwickler-Framework bereitgestellten Mitteln aus der URI auslesen können. Du kannst dann gleich mit dem Schritt Inspizieren von Zugriffsschlüsseln fortfahren.
Wenn ein Nutzer deiner App den Login-Dialog nicht akzeptiert und stattdessen auf „Abbrechen“ klickt, wird er hierhin weitergeleitet:
YOUR_REDIRECT_URI? error_reason=user_denied &error=access_denied &error_description=Permissions+error.
Unter Verhalten bei fehlenden Berechtigungen findest du weitere Informationen dazu, wie sich Apps verhalten sollten, wenn eine Person die Anmeldung abbricht.
Da bei diesem Umleitungsvorgang Browser über den Login-Dialog an URLs in deiner App umgeleitet werden, könnte diese URL mit falschen Fragmenten oder Parametern aufgerufen werden. Wenn deine App davon ausgeht, dass diese Parameter gültig sind, könnten diese falschen Daten von deiner App zu potenziell bösartigen Zwecken missbraucht werden. Deshalb sollte deine App immer prüfen, ob die Person, die die App verwendet, auch die Person ist, von der du die Antwortdaten erhalten hast, bevor du für sie einen Zugriffsschlüssel erstellst. Die Überprüfung der Identität wird je nach erhaltenem response_type unterschiedlich durchgeführt:
code erhalten hast, muss er gegen einen Zugriffsschlüssel, der einen Endpunkt verwendet, getauscht werden. Der Aufruf muss von Server zu Server stattfinden, da dein App-Geheimcode enthalten ist. (Dein App-Geheimcode sollte nie Teil des Client-Codes sein.)token erhalten hast, muss es geprüft werden. Du solltest einen API-Aufruf an einen Inspizierungsendpunkt senden, der angibt, von welcher App und für wen der Schlüssel generiert wurde. Da für diesen API-Aufruf ein App-Zugriffsschlüssel erforderlich ist, darfst du diesen Aufruf nie über einen Client starten. Führe den Aufruf stattdessen von einem Server aus, auf dem du den App-Geheimcode sicher speichern kannst.code als auch token erhältst, solltest du beide Schritte ausführen.Beachte dabei, dass du auch deinen eigenen state-Parameter erstellen und zusammen mit der Anmeldeanfrage Schutz vor CSFR-Angriffen bieten kannst.
Sende eine HTTP-GET-Anfrage an den folgenden OAuth-Endpunkt, um einen Zugriffsschlüssel zu erhalten:
GET https://graph.facebook.com/v7.0/oauth/access_token?
client_id={app-id}
&redirect_uri={redirect-uri}
&client_secret={app-secret}
&code={code-parameter}Für diesen Endpunkt sind einige Parameter erforderlich:
client_id. Deine App-IDs.redirect_uri. Dieses Argument ist erforderlich und muss mit der ursprünglichen request_uri übereinstimmen, die du beim Start des OAuth-Anmeldevorgangs verwendet hast.client_secret. Der eindeutige App-Geheimcode, der im App-Dashboard angezeigt wird. Der App-Geheimcode sollte nie in clientseitigem Code oder in dekompilierbaren Binärdateien enthalten sein. Es ist äußerst wichtig, dass der App-Geheimcode geheim bleibt, da er das Kernstück der Sicherheit für deine App und alle ihre Nutzer darstellt.code. Der Parameter, den du über den Login-Dialog erhalten hast, leitet dich nach oben weiter.Hinweis: Ab Version 2.3 gibt dieser Endpunkt eine korrekte JSON-Antwort zurück. Wenn dein Aufruf keine Version angibt, wird standardmäßig die älteste verfügbare Version verwendet.
Antwort
Die Antwort, die du von diesem Endpunkt erhältst, wird im JSON-Format gegeben und lautet, falls erfolgreich:
{
"access_token": {access-token},
"token_type": {type},
"expires_in": {seconds-til-expiration}
}Falls die Übertragung nicht erfolgreich ist, erhältst du eine Fehlermeldung.
Egal, ob deine App code oder token als response_type vom Login-Dialog verwendet, sie hat immer einen Zugriffsschlüssel erhalten. Du kannst diese Schlüssel über einen Graph API-Endpunkt automatisch prüfen lassen:
GET graph.facebook.com/debug_token?
input_token={token-to-inspect}
&access_token={app-token-or-admin-token}Dieser Endpunkt akzeptiert die folgenden Parameter:
input_token. Der zu inspizierende Schlüssel.access_token: ein App-Zugriffsschlüssel oder ein Zugriffsschlüssel eines Entwicklers der App.Bei der Antwort des API-Aufrufs handelt es sich um ein JSON-Array, das Daten zum inspizierten Schlüssel enthält. Beispiel:
{
"data": {
"app_id": 138483919580948,
"type": "USER",
"application": "Social Cafe",
"expires_at": 1352419328,
"is_valid": true,
"issued_at": 1347235328,
"metadata": {
"sso": "iphone-safari"
},
"scopes": [
"email",
"publish_actions"
],
"user_id": "1207059"
}
}Die Felder app_id und user_id helfen deiner App dabei, zu prüfen, ob der Zugriffsschlüssel für den Nutzer und für deine App gültig ist. Eine vollständige Beschreibung der anderen Felder findest du im Leitfaden zum Abrufen von Informationen zu Zugriffsschlüsseln.
Edge /me/permissions kann aufgerufen werden, um eine Liste von Berechtigungen zu erhalten, die von einem bestimmten Nutzer gewährt oder abgelehnt wurden. Deine App kann damit prüfen, welche der angeforderten Berechtigungen sie bei einem bestimmten Nutzer nicht verwenden kann.
Über Facebook Login kann sich ein Nutzer dazu entscheiden, gewisse Berechtigungen nicht mit deiner App zu teilen. Der Login-Dialog enthält einen Bildschirm, der so aussieht:
Die Berechtigung public_profile ist immer erforderlich und ausgegraut, weil sie nicht abgewählt werden kann.
Wenn ein Nutzer allerdings user_likes („Gefällt mir“-Angaben) in diesem Beispiel abwählt, würde das Auswählen von /me/permissions für die gewährten Berechtigungen dieses Ergebnis zur Folge haben:
{
"data":
[
{
"permission":"public_profile",
"status":"granted"
},
{
"permission":"user_likes",
"status":"declined"
}
]
}Beachte, dass die Berechtigung user_likes verweigert und nicht gewährt wurde.
Es ist in Ordnung, wenn du von einem Nutzer, der App-Berechtigungen abgelehnt hat, diese erneut anforderst, allerdings nur einmal. Du solltest dem Nutzer einen Informationsbildschirm anzeigen, auf dem erklärt wird, warum er die Berechtigung gewähren sollte, und über den du die Berechtigung dann erneut anforderst. Wenn du den Login-Dialog aber wie zuvor auslöst, wird diese Berechtigung dieses Mal nicht mehr angefordert.
Das liegt daran, dass eine einmal abgelehnte Berechtigung nicht mehr über den Login-Dialog angefordert wird, sofern du dies nicht explizit festlegst.
Füge dazu einfach den auth_type=rerequest-Parameter zur Login-Dialog-URL hinzu:
https://www.facebook.com/v7.0/dialog/oauth?
client_id={app-id}
&redirect_uri={redirect-uri}
&auth_type=rerequest
scope=email
Die abgelehnte Berechtigung wird dann erneut über den Login-Dialog angefordert.
An diesem Punkt in deinem Login-Vorgang ist ein Nutzer authentifiziert und bei deiner App angemeldet. Deine App kann jetzt API-Aufrufe im Namen eines Nutzers ausführen. Zuvor sollte die App den Zugriffsschlüssel und den Login-Status der Person speichern, die deine App verwendet.
Nachdem deine App den Zugriffsschlüssel im vorherigen Schritt erhalten hat, sollte er gespeichert werden, damit er allen Teilen der App zur Verfügung steht, wenn sie API-Aufrufe starten. Es gibt dafür keinen bestimmten Vorgang, aber wenn du eine Web-App entwickelst, solltest du den Schlüssel vorzugsweise als Sitzungsvariable zur Identifizierung der Browser-Sitzung für eine bestimmte Person hinzufügen. Wenn du dagegen eine native Desktop- oder mobile App entwickelst, solltest du den Datenspeicher verwenden, der deiner App zur Verfügung steht. Die App sollte den Schlüssel außerdem zusammen mit der user_id in einer Datenbank speichern, um ihn zu identifizieren.
Sieh dir dazu unseren Hinweis zur Größe von Zugriffsschlüsseln im Zugriffsschlüsseldokument an.
Deine App sollte den Login-Status einer Person speichern, da dadurch das unnötige Aufrufen des Login-Dialogs vermieden wird. Egal, für welchen Vorgang du dich entscheidest, vergiss nicht, deine Login-Statusüberprüfung entsprechend anzupassen.
Du kannst Menschen von deiner App abmelden, indem du den von dir hinzugefügten Login-Statusindikator entfernst. Du kannst zum Beispiel die Sitzung löschen, die angibt, dass eine Person angemeldet ist. Du solltest auch den gespeicherten Zugriffsschlüssel löschen.
Das Abmelden einer Person ist nicht gleichzusetzen mit dem Entfernen der Anmeldeberechtigungen (damit wird die bereits gewährte Authentifizierung hinfällig). Dies kann separat durchgeführt werden. Achte bei der Entwicklung deiner App deshalb darauf, dass Personen, die abgemeldet wurden, nicht automatisch wieder zum Login-Dialog weitergeleitet werden.
Menschen können Apps über Facebook.com deinstallieren, ohne dabei mit der App selbst in Berührung zu kommen. Damit Apps dies leichter erkennen können, ermöglichen wir den Einsatz einer Rückruf-URL für das Zurücknehmen einer Autorisierung, die angepingt wird, wenn dieser Fall eintritt.
Einen Rückruf für das Zurücknehmen einer Autorisierung kannst du im App-Dashboard aktivieren. Wechsle einfach zu deiner App und wähle Produkte, Facebook Login und schließlich Einstellungen aus. Es wird ein Textfeld für die Autorisierung der Rückruf-URL widerrufen angezeigt.
Jedes Mal, wenn ein Nutzer die Autorisierung deiner App zurücknimmt, wird ein HTTP POST an diese URL gesendet, der eine signierte Anfrage enthält. In unserem Leitfaden zum Parsen der signierten Anfrage findest du Informationen darüber, wie du dies dekodierst, um die Nutzer-ID herauszufinden, von der der Rückruf ausging.
Personen können anfordern, dass alle Daten gelöscht werden, die eine App über sie von Facebook erhalten hat. Informationen dazu, wie du auf eine solche Anfrage antwortest, findest du unter Rückruf zur Datenlöschungsanfrage.