Portabilität von Zugriffsschlüsseln

In diesem Leitfaden werden einige gängige Szenarien für Portabilität erläutert, sodass du deine eigene App mit der für dich passenden Konfiguration erstellen kannst.

Verwendung von Zugriffsschlüsseln mit verschiedenen App-Arten

Zugriffsschlüssel sind portierbar. Sobald du einen Zugriffsschlüssel erhältst, kannst du ihn auf jedem beliebigen Gerät verwenden. Wenn du Weboberflächen, Mobile Clients und Server miteinander kombinierst, erhältst du eine Mischung aus verschiedenen möglichen Konfigurationen. Diese verschiedenen Konfigurationen bringen jedoch unterschiedliche Vor- und Nachteile in Bezug auf Funktionen und Sicherheit mit sich.

Konfiguration	Vorteile	Nachteile	Sicherheitshinweise
Login- und API-Anfragen erfolgen in einem Web-Client (kurzlebiger Zugriffsschlüssel).	Einfache Implementierung.	Kein Offline-Posten. Kein langfristiger Zugriff. Häufig authentifizieren.
Login- und API-Anfragen erfolgen in einem nativen Mobile oder Web-Client (langlebiger Zugriffsschlüssel).	Weniger häufig authentifizieren.	Kein Offline-Posten.
Login- und API-Anfragen erfolgen in einem Web-Client (langlebiger Zugriffsschlüssel nach Code-Austausch).	Zusätzliche Sicherheit in bestimmten Situationen.	Schwierig zu implementieren Kein Offline-Posten.	Nur in bestimmten Situationen hilfreich.
Login erfolgt in einem nativen Mobile oder Web-Client. API-Anfragen erfolgen auf einem Server (mit langlebigem Zugriffsschlüssel).	Offline-Posten. Mit serverbasierten Aufrufen verfügbare Sicherheitsfeatures hinzufügen.	Client muss Server aufrufen, um als Proxy Aufrufe zu tätigen.	Verwende `appsecret_proof` für alle Aufrufe.
Login erfolgt in einem nativen Mobile oder Web-Client. API-Anfragen erfolgen auf einem Server oder im Client.	Offline-Posten. Nutzergesteuertes Posten vom Client aus	Schwierig zu implementieren	Verwende `appsecret_proof` für alle Aufrufe über den Server.

Login- und API-Anfragen erfolgen in nativem oder Web-Client

Dies ist die einfachste Konfiguration, bei der die Authentifizierung und API-Anfragen auf dem Client erfolgen. Bei diesem Modell gibt es drei mögliche Konfigurationen:

Der native oder Web-Client authentifiziert sich und verwendet für Aufrufe den zurückgegebenen kurz- oder langlebigen Zugriffsschlüssel.
Der Web-Client authentifiziert sich und tauscht über einen Server den kurzlebigen Zugriffsschlüssel gegen einen langlebigen Zugriffsschlüssel aus. Dieser Zugriffsschlüssel wird zurück zum Web-Client gesendet, der diesen für API-Aufrufe verwendet.
Der Web-Client authentifiziert sich und tauscht über einen Server den kurzlebigen Zugriffsschlüssel gegen einen langlebigen Zugriffsschlüssel aus. Der Server sendet einen Code an den Client. Der Client tauscht den Code gegen einen langlebigen Zugriffsschlüssel und verwendet ihn für API-Aufrufe. Diese Konfiguration wird selten verwendet.

Ablauf in nativem oder Web-Client

Web-Client-Ablauf mit langlebigem Zugriffsschlüssel

Web-Client-Ablauf mit Code-Austausch

Client-Login und Server-API-Aufrufe

In dieser gängigen Konfiguration erfolgt die Authentifizierung auf dem Client, aber alle API-Aufrufe werden vom Server im Namen des Clients ausgeführt. Der Server kann bei Aufrufen den Parameter appsecret_proof verwenden, um die Sicherheit zu erhöhen.

Client-Login und Client- oder Server-API-Aufrufe

Diese Konfiguration ist eine Kombination aus den oben genannten Ansätzen.

Zugriffsschlüssel mithilfe des SDKs festlegen

Es gibt verschiedene Möglichkeiten, in unseren SDKs anzugeben, welcher Zugriffsschlüssel bei einem API-Aufruf verwendet werden soll.

Die Facebook Android SDK setCurrentAccessToken-Methode weist den accessToken-Parameter auf.
Die Facebook iOS SDK setCurrentAccessToken-Methode weist den token-Parameter auf.
Die Facebook JavaScript SDK FB.api()-Methode weist den access_token-Parameter auf.