security - 高效的 OAuth2.0 服务器/提供程序如何工作？

Question

我可能需要为我正在创建的 API 实现 OAuth2.0 服务器。此 API 将允许第 3 方代表用户执行操作。

OAuth2.0 有 3 个电源调用。首先，有一个提示用户同意的调用。这将返回 code .第二个是哪里code换成了 access token .最后，access token用于代表用户调用 API。

为了实现，我想第一次调用会生成一个随机字符串，作为 code . code然后使用指向当前用户的指针和随机 HMAC Key 存储在数据库中。 ，则随机数据作为code返回给第三方.

当第 3 方请求 access token 时，生成另一条随机数据并与code连接起来。 .此字符串使用 HMAC key 签名从第 1 步开始，然后此签名字符串和签名与签名一起返回以形成 access token .

当 API 调用发生时，hmac key对应于提供的 access_token从数据库中检索。 access_token的签名使用 hmac key 进行验证。

用户只需从其授权 HMAC key 列表中删除 HMAC key 即可撤销 3rd 方访问。此外，但只是签署随机数据，我可以避免存储每个创建的每个 access_token，而是维护一个 hmac key 的简短列表。

无论如何，这是我第一次尝试思考这个问题。令人惊讶的是，关于有效实现 OAuth2.0 服务器端的信息很少。我希望在数据库中保留尽可能少的信息。签署随机数据然后稍后撤销 HMAC key 的优点是我不必存储每个 access token由每个授权调用生成。

需要思考!必须有更好的方法!

编辑:

我不是在寻找实现。不过还是谢谢你!此外，我假设整个系统将通过 HTTP 运行。另外，我在谈论纯 OAuth2.0 流程，我不是在谈论带有签名和客户端 key 的 OAuth1.0。我问的是如何设计 OAuth2.0 服务器背后的密码学，该服务器的工作方式与(例如)Google 的 OAuth2.0 流程的工作方式类似。

Answer 1

我对此没有确切的答案，但让我们试着把这些碎片拼凑起来——
i) 我不太确定您是否需要在数据库中长时间保存授权码。这就是 Facebook 所说的——

New security restrictions for OAuth authorization codes We will only allow authorization codes to be exchanged for access tokens once and will require that they be exchanged for an access token within 10 minutes of their creation. This is in line with the OAuth 2.0 Spec which from the start has stated that "authorization codes MUST be short lived and single use". For more information, check out our Authentication documentation.

查看此链接，https://developers.facebook.com/roadmap/completed-changes/ (12月5日，变化)。

ii) 直到步骤 1 为止，将授权码和 HMAC key 保存在数据库中。 让我们将授权代码保留 10 分钟(或您认为需要的任何内容)，然后删除授权代码。

iii) 假设您有一个验证客户端凭据的单点登录服务。当客户端应用程序访问 token 交换端点(访问 token 的身份验证代码)时，您需要获取 HMAC key 并返回访问 token 。 为什么不添加(一些随机数据 + 时间戳 + 客户 ID/客户名称(或可用于唯一标识用户的内容))并使用 key 对其进行签名并将所有这些数据作为访问 token 返回。
您可以考虑使用新的 HMAC key 并替换旧的。

iv) 当客户端使用 token 命中任何 API 端点时，让服务内部调用 一个 CustomerIDExtractorService，它从数据库中获取 HMAC key 并解密访问 token 并将客户 ID 返回到相关的 API .然后，独立进程可以使用客户 ID 来获取数据。所以基本上，我要求您将登录/ token 生成/ token 信息提​​取过程分离到一个单独的单元。

让我们尝试将其映射到 Google 如何做这样的事情
i) 您使用应用程序并登录 Google Oauth。 (让来自谷歌的黑匣子 X 处理登录)。
ii) 您的应用到达 token 交换端点 -> 服务在内部检查代码是否有效。如果是，该服务会结合一些数据 + customerID 并对其进行签名并将其作为访问 token 返回给应用程序。
iii) 应用程序现在点击(比如)google+ 端点。在内部，服务将 token 传输到黑盒 X，黑盒 X 解密 token 并将客户 ID 返回给 G+ 服务。 g+ 然后将 C_ID 映射到相关客户数据。

另一个建议
根据应用程序请求的范围，您可以向访问 token 添加更多信息。也许创建一个 JSON 对象并根据应用程序选择的范围添加/删除字段。将 JSON 字符串签名为访问 token 。