Warum sollte ich `client_secret` übermitteln, um ein `access_token` zu erhalten?

Question

Um ein access_token von Facebook zu erhalten, müssen Sie Ihre app_id El code die Sie nach der Autorisierungsanfrage erhalten, und die App secret_key .

Warum sollte ich EVER meinen geheimen Schlüssel übermitteln? Das scheint mir sehr unsicher zu sein. Ist dies eine Anforderung der OAuth 2.0-Spezifikation?

Eine damit zusammenhängende Frage: Warum sollte ich eine app_id wenn mein Ersuchen bereits mit meinem Namen signiert ist consumer_key ?

Ich habe eine funktionierende Anwendung, ich verstehe nur diese Anforderungen nicht.

Answer 1

Dies ist eine Anforderung der OAuth 2.0-Spezifikation, Abschnitt 4.1.3 .

Wenn der Mandantentyp vertraulich ist oder ihm ein Mandatsnachweis ausgestellt wurde (oder andere Authentifizierungsanforderungen zugewiesen), wird der Client MUSS sich gegenüber dem Autorisierungsserver authentifizieren wie beschrieben in Abschnitt 3.2.1

Und Abschnitt 3.2.1 bezieht sich auf Abschnitt 2.3 . Konkret, Abschnitt 2.3.1 sagt:

Alternativ kann der Autorisierungsserver die Aufnahme der Client-Anmeldeinformationen in den Anforderungskörper unter Verwendung der folgenden Parameter:

client_id

   REQUIRED.  The client identifier issued to the client during

   the registration process described by Section 2.2.

kunden_geheimnis

   REQUIRED.  The client secret.  The client MAY omit the

   parameter if the client secret is an empty string.

Es gibt in der Tat andere Möglichkeiten, die OAuth 2.0 bietet, aber mit der Wahl dieses Ansatzes liegt Facebook voll im Rahmen der Spezifikation. Jetzt warum Facebook hat sich für diesen Ansatz entschieden, den wahrscheinlich nur Facebook beantworten kann.

Answer 2

Abgesehen davon, dass dies eine Anforderung von Oauth2 ist, muss das client_secret in diesem Schritt verwendet werden, um zu überprüfen, ob Sie tatsächlich derjenige sind, den Sie angeben.

Es läuft alles darauf hinaus, warum der Prozess so ist, wie er ist...

Der "Code", den Sie bei der ersten Anfrage zurückerhalten, ist vom Standpunkt der Sicherheit aus gesehen ziemlich schwach. Er könnte auf dem Weg zurück zu Ihnen im Umleitungslink gekapert werden, der meiner Erfahrung nach häufig zu Landing Pages ohne SSL-Schutz führt. Selbst wenn Sie Ihre gesamte Website zu 100 % mit HTTPS verschlüsseln, ist nicht alles völlig sicher. Jemand könnte den Code finden, indem er sich die Anfrage-URLs ansieht, die in den Zugriffsprotokollen Ihres Webservers aufgezeichnet werden.

Selbst wenn Sie den Zugang zu Ihren Servern mit den strengsten Sicherheitsvorkehrungen jenseits des Buckingham Palace versehen haben, wissen Sie, dass jemand Ihre Protokolle irgendwann an einem weniger sicheren Ort "archivieren" wird, wenn Sie mehr als ein paar Jahre auf dem Markt sind. Wahrscheinlich auf einem USB-Stick, den sie bei Starbucks zurückgelassen haben...

Dies lässt sich nicht vermeiden, wenn Sie einen serverseitigen API-Flow verwenden. Im Gegensatz zu Javascript, das innerhalb des Client-Browsers ausgeführt wird, können Sie den temporären Code nicht nach dem Hash hinzufügen, um zu verhindern, dass er protokolliert wird, da Browser-Clients nichts nach der Hash-Marke mit der Anfrage senden. JS kann die Redirect Url abfangen und die Daten nach dem Hash-Tag auslesen. Deshalb gibt es den JS Oauth2 Flow, der einfach den access_token zurückgibt, ohne den zusätzlichen Zwischencode zu verwenden. Keine Client_Secret Notwendigkeit auf der JS-Seite entweder, was gut ist, wie es in der Regel auf, wenn Sie Passwörter und geheime Schlüssel in Javascript setzen verpönt ist.

Um nun zu verhindern, dass dieser Zwischencode von einem Bösewicht verwendet wird, um ein Zugangstoken zu erhalten, werden die Client_ID und das Client_Secret mitgeschickt, damit der API-Server authentifizieren kann, dass Sie derjenige sind, der Sie vorgeben zu sein, und dass Sie die Berechtigung haben, den Code gegen ein Zugangstoken einzulösen. Nichts ist besser als ein gemeinsames Geheimnis!

Da der Code nur ein sehr kurzes Zeitfenster hat, bevor er abläuft - im Grunde ist er dafür gedacht, dass Sie ihn sofort gegen einen access_token eintauschen -, ist die Gefahr, dass jemand den Code stiehlt und versucht, ein Client_Secret zu erzwingen, nicht allzu groß.

Die Kombination aus einem kurzen Zeitfenster für die Nutzung und dem client_secret (natürlich über SSL) liefert ein Geheimnis, das Sie später mit Ihren Client-Anmeldedaten austauschen

Answer 3

Beachten Sie die Worte.... NICHT EMPFOHLEN.

2.3.1. Client-Passwort

Clients, die im Besitz eines Client-Passworts sind, KÖNNEN das HTTP Basic [ ] dem Autorisierungsserver zu authentifizieren. Der Client-Identifikator wird mit dem "application/x-www-form-urlencoded" Kodierungsalgorithmus gemäß Anhang B kodiert, und der kodierte Wert wird als Benutzername verwendet; das Client Passwort wird mit demselben Algorithmus verschlüsselt und als Kennwort verwendet. Der Autorisierungsserver MUSS die HTTP Basic Authentifizierungsschema für die Authentifizierung von Clients, denen ein Client-Passwort.

Zum Beispiel (mit zusätzlichen Zeilenumbrüchen nur zu Anzeigezwecken):

 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

Alternativ dazu KANN der Autorisierungsserver die Einbeziehung des Client-Anmeldeinformationen in den Anforderungskörper unter Verwendung der folgenden Parameter:

c ERFORDERLICH. Die Client-Kennung, die dem Client während des dem Client während des in Abschnitt 2.2 beschriebenen Registrierungsprozesses vergeben wurde.

c ERFORDERLICH. Das Geheimnis des Kunden. Der Client KANN das Parameter weglassen, wenn das Client-Geheimnis eine leere Zeichenkette ist.

Die Aufnahme der Client-Anmeldeinformationen in den Anforderungskörper unter Verwendung der beiden ist NICHT EMPFOHLEN und SOLLTE auf Clients beschränkt sein, die nicht in der Lage sind nicht in der Lage sind, das HTTP Basic Authentifizierungsschema (oder andere Passwort-basierte HTTP-Authentifizierungsschemata verwenden können). Die Parameter können nur im Request-Body übertragen werden und MÜSSEN NICHT im Request-Body enthalten sein. Anfrage-URI enthalten.

Zum Beispiel kann eine Anfrage zur Auffrischung einer acce den Body-Parametern (mit zusätzlichen Zeilenumbrüchen zur Anzeige nur zu Anzeigezwecken):

 POST /token HTTP/1.1
 Host: server.example.com
 Content-Type: application/x-www-form-urlencoded

 grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
 &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

Der Autorisierungsserver MUSS die Abschnitt 1.6 beschrieben, wenn er Anfragen mit Passwortauthentifizierung sendet.

Da diese Client-Authentifizierungsmethode ein Kennwort erfordert, muss die Autorisierungsserver jeden Endpunkt, der diese Methode verwendet, gegen Folgendes schützen MUSS Brute-Force-Angriffe schützen.