5

我们正在编写一个与 OAuth2 api 集成的插件。

棘手的部分是我们不能像在大多数集成中那样对重定向 URI 进行硬编码，因为客户端可以在他们控制的任何域上安装这个插件（想想 Wordpress 插件），并且访问令牌需要重定向回他们的自定义 url。

我们看到您也可以state在 OAuth2 中设置参数。因此，我们可以将重定向 URI 硬编码为http://oursite.com/callback并将状态设置为https://[CUSTOM_URL].

然后http://oursite.com/callback会做一个额外的重定向到自定义 URL，传递访问令牌。

然而，这似乎是一个安全漏洞，因为一旦用户验证了应用程序，其他人可能会出现并使用参数中的自己的 url 重新验证state。然后它会很高兴地重定向到他们的错误 url 并将访问令牌传递给他们。

那么人们如何设置重定向 uri 可以变化的 OAuth2 集成呢？谢谢！

PS 我们想到的一个解决方案是仅在重定向 uri 是我们控制的 url时才允许使用参数。state然后我们可以创建另一个验证页面，再次提示用户：“您是否要允许https://customurl.com访问您的帐户...”。但我们认为可能有更好的方法。

4

2 回答 2

0

对于动态客户端地址，可能值得考虑使用基于 localhost 的重定向 URI。这听起来可能违反直觉，但由于 OAuth2 是基于浏览器/httpclientlib 的协议，因此它可以工作。来自服务器授权端点的重定向是由您自己的浏览器完成的，因此 localhost 作为 redirect_uri 总是被正确解析。因此，无论您在何处部署应用程序，您仍然可以修复 redirect_uri。

该解决方案也有其含义，您应该考虑架构和安全后果。基于本地主机的redirect_uri 非常适合隐式授权场景（即javascript 客户端），但我认为对于授权代码授权场景（即远程Web 应用程序），您应该使用可远程访问的主机名。

于 2013-07-19T12:43:24.863 回答
0

对我来说，您的方向是正确的，恕我直言，这是向州政府传递信息的唯一方法。为了没有安全问题，我建议您不要传递状态中的 URL，而是传递关键字。然后在您的应用程序中有一个处理http://oursite.com/callbackURL 的映射，并且只有当您的映射中存在关键字时，您才能从该映射重定向到相应的 URL。

于 2020-05-01T18:05:44.847 回答