我们有一个应用程序可以发送包含深层链接的电子邮件，并且它使用OAuth2。当用户已经“登录”（具有有效的访问令牌）时，深度链接可以正常工作，但是当令牌过期/没有等时，深度链接会中断。原因是应用程序接收到具有特定深度URL的请求，向auth服务器发出一个请求，其中包含一个重定向URL到自身（它是主页面，而不是原始请求中的深层链接，即我们为应用程序配置的重定向URL），以及登录进展顺利的时候，auth服务器执行重定向，应用程序显示主页面，忘记原始深层链接请求。值得一提的是，所有这些都发生在一个浏览器窗口/标签中（要求不要打开其他标签或使用弹出窗口）。
我有一个想法（滥用？）“状态”请求参数，即auth服务器需要在重定向中逐字使用，并且它将包含允许应用程序显示的信息（如应用程序中的链接）想要的页面。我不确定“状态”参数是否应该像这样使用，它似乎是为CSRF预防而设计的，而不是像这样的自定义逻辑。
另一个可行的选项是基于服务器与完整的重定向URL与配置的URL不匹配的事实，只检查它是否以配置的为前缀（因为OAuth2规范没有强制要求，它说完全匹配应该完成）。因此，由于我们的重定向URL是深层链接，并且配置的URL是其前缀，因此它确实有效。但是，当服务器决定匹配完整的URL时，此行为将中断（并且它是在Spring Security中编写的，并且很容易更改此行为，只需使用已提供lib的不同匹配器类：https://github.com/spring-projects/spring-security-oauth/blob/ec215f79f4f73f8bb5d4b8a3ff9abe15b3335866/spring-security-oauth2/src/main/java/org/springframework/security/oauth2/provider/endpoint/ExactMatchRedirectResolver.java ）。我想使用更安全的东西，这种方式不会对抗OAuth2。
有更好的方法吗？
答案 0 :(得分：2)
the time is adjusted accordingly对于'state'参数，描述以文本开头：
客户端用于维护请求和回调之间状态的不透明值。
对我而言，这意味着它完全是出于您描述的目的。在我曾经使用的应用程序中，我们传递了一个state参数值，我们可以在回调响应中包含所有必要的状态。在编码为安全的查询参数值之前，我们看起来像这样：nonce=<nonce value>&location=<deep link>。当回调URI收到请求时，它将检索'state'参数的值，然后解析它，验证nonce并重定向到该位置。