Deep-Links mit OAuth2 verloren wegen Redirects

Question

Wir haben eine Anwendung, die E-Mails sendet, die Deep-Links enthalten, und es verwendet OAuth2. Deep-Linking funktioniert gut, wenn der Benutzer bereits "angemeldet" ist (hat ein gültiges Zugriffs-Token), bricht aber ab, wenn das Token veraltet ist/keine vorhanden ist. Der Grund ist, dass die Anwendung die Anfrage mit der spezifischen tiefen URL empfängt , sendet eine Anfrage an den Authentifizierungsserver mit einer Weiterleitungs-URL an sich selbst (und es ist die Hauptseite, nicht der Deep-Link in der ursprünglichen Anfrage, dh die Weiterleitungs-URL, die wir einmal für die Anwendung konfiguriert haben) und wenn die Anmeldung gut verläuft , führt der Authentifizierungsserver die Umleitung durch, und die Anwendung zeigt die Hauptseite an, und die ursprüngliche Deep-Link-Anforderung wird vergessen. Es kann wichtig sein zu erwähnen, dass dies alles in einem einzigen Browserfenster/Tab passiert (Anforderung, keine anderen Tabs zu öffnen oder Popups zu verwenden).

Ich hatte eine Idee zu verwenden (missbrauchen?) Die 'State' Anfrage param, dass der Auth-Server benötigt wird, wörtlich in der Weiterleitung zu verwenden, und es würde Informationen (wie eine Verknüpfung innerhalb der Anwendung) die Anwendung zu ermöglichen zeige die gewünschte Seite an. Ich bin mir nicht sicher, ob der "State" -Param so verwendet werden soll, er scheint für CSRF-Prävention konzipiert zu sein, nicht für benutzerdefinierte Logik wie diese.

Eine andere funktionierende Option basiert auf der Tatsache, dass der Server die vollständige Umleitungs-URL nicht mit der konfigurierten URL vergleicht, sondern lediglich prüft, ob sie dem konfigurierten vorangestellt ist (wie die OAuth2-Spezifikation dies nicht vorschreibt) , es sagt, dass vollständige Übereinstimmung SOLLTE getan werden). Da unsere Weiterleitungs-URL der Deep-Link ist und die konfigurierte URL ihr Präfix ist, funktioniert sie. Dieses Verhalten bricht jedoch, wenn der Server entscheidet, vollständige URLs zu entsprechen (und es ist in Spring Security geschrieben und es ist ziemlich einfach, dieses Verhalten zu ändern, verwenden Sie einfach eine andere Matcher-Klasse, bereits mit der Lib bereitgestellt: https://github.com/spring-projects/spring-security-oauth/blob/ec215f79f4f73f8bb5d4b8a3ff9abe15b3335866/spring-security-oauth2/src/main/java/org/springframework/security/oauth2/provider/endpoint/ExactMatchRedirectResolver.java). Ich würde gerne etwas Sichereres verwenden, das nicht gegen OAuth2 kämpft.

Gibt es einen besseren Weg, dies zu tun?

Answer 1

In the specification für die ‚Zustand‘ Parameter, beginnt die Beschreibung mit dem Text:

einen vom Client verwendeten opaken Wert Zustand zwischen der Anforderung und Rückruf zu halten.

Für mich bedeutet dies, dass es genau für den Zweck gedacht ist, den Sie beschreiben. In einer Anwendung, an der ich gearbeitet habe, haben wir einen Wert für den state -Parameter übergeben, in den wir bei der Callback-Antwort den gesamten erforderlichen Status aufnehmen können. Vor der Codierung, um als Abfrageparameterwert sicher zu sein, sah unsere wie folgt aus: nonce=<nonce value>&location=<deep link>. Wenn der Rückruf-URI eine Anforderung empfängt, ruft er den Wert des Parameters "state" ab und parst dies anschließend, überprüft die Nonce und leitet sie an den Standort weiter.