2017-10-06 2 views
0

Ich habe verschiedene OAuth-Ströme gelesen und habe Verwirrung über den Autorisierungscode-Fluss. Es wird gesagt, dass Authorization Code Flow sicherer ist, denn selbst wenn der Autorisierungscode während der Übertragung entführt wird, ist er für den Hacker nutzlos, da der Hacker die Client - ID und das Client - Geheimnis benötigt, um das Zugriffstoken zu erhalten Client-Anfragen für Access-Token nach dem Erhalt der Autorisierungs-Code, hackt Hacker die Übertragung und erhalten das Access-Token? Ich weiß es nicht, aber es sieht so aus, als ob der Autorisierungscode nur eine zusätzliche Sicherheitsschicht hinzufügt, aber die Zugriffstoken nicht vollständig sichert. Bin ich richtig? Bitte korrigieren Sie mich.Können Zugriffstoken im Autorisierungscode-Flow OAuth abgefangen werden?

Antwort

0

Der typische Anwendungsfall für einen Strömungsautorisierungscode ist, dass die Token-Anforderung (dh derjenige, der den Autorisierungscode für einen Zugriffstoken austauscht) über eine TLS-Rückkanal geschützt getan wird, was bedeutet, dass der Angreifer nicht, um es zu bekommen - es sei denn, Er ist in der Lage, SSL zu brechen. In diesem Fall gibt es viel größere Probleme.

Aber für Front-Kanal-Anwendungsfall, d. H. Eine In-Browser-Javascript-Anwendung oder Single Page Application haben Sie Recht: Ein Hacker könnte fast genauso einfach die Token-Anfrage als Redirect abfangen. Das ist auch der Grund, warum dieser Anwendungsfall keinen vertraulichen Client verwenden kann, da das Geheimnis zu leicht offen gelegt würde.

+0

Hallo, Sie sagten "Autorisierungscode Fluss ist, dass die Token-Anfrage (dh die, die den Autorisierungscode für ein Zugriffs-Token austauscht) über einen TLS-geschützten Backchannel erfolgt", aber wenn dieser Flow über TLS-geschützten Backchannel verwendet wird, Warum kann der Authentifizierungsserver kein Zugriffstoken anstelle des Authentifizierungscodes zurückgeben, wenn ein Benutzer eine App authentifiziert? –

+0

Da dies im Front-Kanal mit dem Autorisierungscode-Fluss wäre, per Definition –

+0

Hi @HansZ. Ich stimme dem zweiten Teil Ihrer Antwort nicht zu. Der RFC6749 verhindert nicht, dass öffentliche Clients den Autorisierungscode-Fluss verwenden. Um die Ausgabe eines Zugriffstokens mit einer abgefangenen Auth. Mit diesem Client-Typ führt der RFC7636 einen Code-Verifier ein. Der Entwurf https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03#section-5.1.1 zeigt an, dass dies der bevorzugte Weg für native Apps ist. –

Verwandte Themen