Die Desktop- und Mobile-Apps sind eingebettete Browser in der App, um den gesamten OAuth 2.0-Prozess abzuschließen
Der Prozess ist in der Abbildung dargestellt
OAuth2.0 Web 1) AuthCode an die angegebene Web-redirectUri zurückgeben (diese URI wird vom App-Entwickler konfiguriert) 2) Um das Token zu ändern, müssen Sie die clientId und clientSecret weitergeben, um die Client-Identität zu überprüfen (die vom Backend-Service der Anwendung erhalten wird).
Unter Berücksichtigung der oben genannten beiden Punkte, 1) Weil nicht die RedirectUri-Erkennung der Webanwendung ungültig ist 2) Da es keinen Backend-Service gibt, ist Secret nicht sicher Dann ist der Angriff, dem wir begegnen könnten, wie in der untenstehenden Abbildung gezeigt: Es könnte eine bösartige Anwendung vorliegen, die AuthCode abfängt, um eine Nachricht an den Autorisierungsserver zu senden, um das Token zu erhalten, sodass das Token ohne die Genehmigung des Kunden an die Anwendung erhalten wird, sondern an eine andere offizielle Anwendungsautorisierung, was den Zweck des Angriffs erfüllt.
Lösung:
1. Der Client erzeugt eine zufällige Zeichenkette: Code Verifier und speichert diese zufällige Zeichenkette code_challenge = transform(code_verifier, [Plain| S256]) Wenn die Transformationsmethode einfach ist, ist Code Challenge äquivalent zum Code Verifier Wenn die Transformationsmethode S256 ist, so ist die Code-Herausforderung gleich dem Sha256-Hash des Code-Verifizors 2. Bringen Sie eine Code-Challenge auf die Autorisierungscode-Anfrage und wie man eine Code-Challenge generiert. Diese beiden sind an den vom Server ausgegebenen Autorisierungscode gebunden 3. Nach Erhalt des Autorisierungscodes bringt der Client beim Austausch des Autorisierungscodes gegen das Access Token den ursprünglich generierten Code-Verifizierer mit. Der Server berechnet den Code-Verifier nach der bound-Transformation-Methode, vergleicht das berechnete Ergebnis mit der bound code-Herausforderung und gibt einen Access Token aus, falls dieser konsistent ist. |