2

背景：我正在使用 node.js 和 express 来创建 API。我已经在我的 API 服务器中以标准的消费者/用户密钥/秘密方式实现了 OAuth（与 Twitter、Facebook 等相同的方式）。我希望第 3 方能够以与这些常见 API 相同的方式连接到我的 API。

通常，客户端会与应用程序令牌/秘密连接（例如，您以 Facebook 开发人员的身份创建 Facebook 应用程序，这些都提供给您）。但是，有时客户端无法为应用程序提供秘密，因为代码是以不安全的方式实现的。具体来说，我指的是 Javascript 库。例如，开发人员不希望在 Javascript 代码中公开他们的应用程序机密，因为它是明文并且可能被恶意用户读取。

我注意到 Facebook 避免了这个问题。开发人员只需向 Javascript 库提供应用程序令牌（不是秘密）。我不明白如何在不从根本上使我的库不安全的情况下为我的 API 提供类似的选项。即，如果 Javascript 客户端库向 API 发出请求而没有提供安全的令牌/秘密，那么 OAuth API 如何对这些请求进行身份验证？

从理智上讲，我能想到的最佳解决方案是通过 HTTPS 连接在 Javascript 客户端库和 API 服务器之间进行某种令牌切换，以便返回一个秘密供库使用。不过，我不太确定如何确保此交接以防止欺骗。

4

1 回答 1

2

在大多数情况下，最好遵循标准而不是实现一些自定义方式。OAuth2在最新草案 (28) 中指定了 4 种方法来执行授权授予流程。隐式流程是您在 Facebook 上看到的流程。

正如标准所说：

在隐式授权流程期间发布访问令牌时，授权服务器不会对客户端进行身份验证。在某些情况下，可以通过用于将访问令牌传递给客户端的重定向 URI 来验证客户端身份。访问令牌可能会暴露给资源所有者或其他有权访问资源所有者的用户代理的应用程序。

隐式授权提高了某些客户端（例如作为浏览器内应用程序实现的客户端）的响应能力和效率，因为它减少了获取访问令牌所需的往返次数。然而，这种便利性应该与使用隐式授权的安全隐患进行权衡，尤其是当授权码授权类型可用时。

它有一些安全缺陷。

但据我所知，其他方法对你不起作用，因为它们会将秘密暴露给客户端（第三方网站所有者）或资源所有者（用户），所以你应该坚持下去。

于 2012-07-09T18:23:47.180 回答