Um ein access_token von Facebook zu erhalten, müssen Sie Ihre app_id , die code , die Sie nach der Autorisierungsanfrage erhalten haben, und die secret_key Ihrer App übertragen.
Warum sollte ich EVER meinen geheimen Schlüssel übertragen? Dies scheint offensichtlich unsicher zu sein. Ist dies eine Anforderung der Spezifikation OAuth 2.0?
Als verwandte Frage: Warum muss ich app_id übertragen, wenn meine Anfrage bereits mit meinem consumer_key signiert ist?
Ich habe eine funktionierende App, ich verstehe diese Anforderungen einfach nicht.
Dies ist eine Anforderung der Spezifikation OAuth 2.0, Abschnitt 4.1. 3 .
Wenn der Clienttyp vertraulich ist oder Clientanmeldeinformationen ausgegeben wurden (oder andere Authentifizierungsanforderungen zugewiesen), muss der Client authentifizieren Sie sich mit dem Autorisierungsserver wie in beschrieben Abschnitt 3.2.1
Und Abschnitt 3.2.1 bezieht sich auf Abschnitt 2.3 . Insbesondere Abschnitt 2.3.1 sagt:
Alternativ kann der Authorization Server die Einbindung des Clientanmeldeinformationen im Anforderungshauptteil mithilfe des Folgenden Parameter:
client_id
%Vor%client_secret
%Vor%
Es gibt zwar andere Möglichkeiten, die OAuth 2.0 bietet, aber durch die Wahl dieses Ansatzes liegt Facebook innerhalb der Spezifikationen. Nun warum Facebook sich für diesen Ansatz entschieden hat, kann wahrscheinlich nur Facebook beantworten.
Neben der Anforderung von Oauth2 muss der client_secret in diesem Schritt verwendet werden, um zu bestätigen, dass Sie tatsächlich die Person sind, die Sie beanspruchen.
Es läuft alles darauf hinaus, warum der Prozess so ist wie er ist ...
Der 'Code', den Sie von der ersten Anfrage erhalten, ist aus Sicherheitsgründen ziemlich schwach. Es könnte auf dem Weg zurück zu Ihnen in den Weiterleitungslink gekapert werden, den ich oft auf Zielseiten ohne SSL-Schutz gesehen habe. Selbst wenn Sie 100% HTTPS auf Ihrer Website haben, ist alles nicht völlig sicher. Jemand könnte den Code finden, wenn er die Anforderungs-URLs anschaut, die in den Zugriffsprotokollen Ihres Webservers geloggt werden.
Auch wenn Sie die engste Sicherheitsumgebung auf dieser Seite des Buckingham Palace haben, die den Zugang zu Ihren Servern kontrolliert, wenn Sie das Tech-Rodeo mehr als ein paar Jahre gefahren sind, wissen Sie, dass jemand irgendwann Ihr Archiv archiviert Logs irgendwo weniger als ideal sicher. Wahrscheinlich auf einem USB-Schlüssel, den sie bei Starbucks hinterlassen haben ...
Nichts kann nicht vermieden werden, wenn Sie einen serverseitigen API-Flow verwenden. Im Gegensatz zu JavaScript, das im Clientbrowser ausgeführt wird, können Sie den temporären Code nicht nach dem Hash hinzufügen, um zu verhindern, dass er protokolliert wird, da Browserclients nichts über die Hash-Markierung mit der Anforderung senden. JS kann die Weiterleitungs-URL abfangen und nach dem Hash-Tag Daten auslesen, deshalb gibt es JS-Oauth2-Fluss, der einfach das access_token ohne den zusätzlichen Zwischencode-Song und Tanz zurückgibt. Kein Client_Secret benötigt auch auf der JS-Seite, was gut ist, wie es allgemein missbilligt wird, wenn man Passwörter und geheime Schlüssel in Javascript steckt.
Um zu verhindern, dass dieser Zwischencode von einem Übeltäter verwendet wird, um ein Zugriffstoken zu erhalten, werden die Client_ID und Client_Secret gesendet, damit der API-Server authentifizieren kann, dass Sie der Berechtigte sind und die Berechtigung besitzen um den Code für ein access_token einzulösen. Nichts geht über ein geteiltes Geheimnis!
Da der Code ein sehr kurzes Fenster hat, bevor er abläuft - im Grunde für Sie gedacht, um ihn sofort für ein access_token einzulösen - ist die Gefahr, dass jemand Code stiehlt und versucht, einen Client_Secret brutal zu erzwingen, nicht allzu wahrscheinlich.
Die Kombination aus einem kurzen Anwendungsfenster und dem client_secret (natürlich über SSL) bietet eine Möglichkeit, die Sie später mit Ihren Client-Anmeldeinformationen austauschen können
Beachten Sie die Worte .... NICHT EMPFOHLEN.
2.3.1. Client-Passwort
Clients, die ein Client-Passwort besitzen, dürfen das HTTP Basic verwenden Authentifizierungsschema wie in [RFC2617] definiert, mit zu authentifizieren der Autorisierungsserver. Die Client-ID wird mit dem Code codiert "application / x-www-form-urlencoded" Verschlüsselungsalgorithmus per Anhang B, und der codierte Wert wird als Benutzername verwendet; der Kunde Das Passwort wird mit dem gleichen Algorithmus codiert und verwendet Passwort. Der Autorisierungsserver MUSS das HTTP Basic unterstützen Authentifizierungsschema für die Authentifizierung von Clients, die a Client-Passwort.
Zum Beispiel (mit zusätzlichen Zeilenumbrüchen nur für Anzeigezwecke):
%Vor%Alternativ kann der Authorization Server die Einbindung des Clientanmeldeinformationen im Anforderungshauptteil mithilfe der folgenden Informationen Parameter:
Client-ID ERFORDERLICH. Die Client-ID, die während des Vorgangs an den Client ausgegeben wurde der Registrierungsprozess beschrieben in Abschnitt 2.2.
client_secret ERFORDERLICH. Das Client-Geheimnis. Der Kunde kann die Parameter, wenn das Clientgeheimnis eine leere Zeichenfolge ist.
Einschließen der Clientanmeldeinformationen in den Anforderungshauptteil unter Verwendung der beiden Parameter wird nicht empfohlen und sollte auf Kunden beschränkt sein, die nicht in der Lage sind das HTTP Basic Authentifizierungsschema (oder anderes) direkt zu verwenden kennwortbasierte HTTP-Authentifizierungsschemata). Die Parameter können nur in der Anfrage-Körper übertragen werden und dürfen nicht in die aufgenommen werden Anfrage-URI.
Zum Beispiel eine Anforderung zum Aktualisieren eines Zugriffstokens (Abschnitt 6) mit die Körperparameter (mit zusätzlichen Zeilenumbrüchen für Anzeigezwecke) nur):
%Vor%Der Autorisierungsserver MUSS die Verwendung von TLS wie in beschrieben erfordern Abschnitt 1.6 beim Senden von Anfragen mit Passwort-Authentifizierung.
Da diese Client-Authentifizierungsmethode ein Passwort beinhaltet, muss der Autorisierungsserver MUSS jeden Endpunkt schützen, gegen den er verwendet wird Brute-Force-Angriffe.
Tags und Links oauth facebook oauth-2.0 access-token