4

我们正计划实施 OAuth2 规范并正在审查“访问令牌”实施。看起来规范为实现者提供了很大的自由度，我们正在寻找一些最佳实践：

  1. 在访问令牌中放入什么？我们希望在尺寸和实用性之间取得良好的平衡。我意识到这是非常特定于应用程序的，但也许有些东西确实值得拥有。

到目前为止，我们确定了以下领域：

  • 用户标识符
  • 截止日期
  • 版本（以便我们将来可以更改格式）
  • 客户端标识符（即请求令牌的应用程序）

一些附加属性（例如密码哈希）将存储在数据库中并在身份验证期间进行查找（使用令牌中的字段作为“密钥”）。

  1. 如何保护它？

我们倾向于安全地签署访问令牌 (HMAC)，以便我们知道它是否被篡改。然后每个人都可以读取令牌中的字段。

另一种方法是加密（AES）整个事物并使其对用户完全不透明。这使它变得更大（以字节计）。看起来 FB 现在正在使用加密令牌 (http://developers.facebook.com/blog/post/572/)

关于行业最佳实践的任何建议？

谢谢，彼得

4

1 回答 1

1

只要您可以将您发出的访问令牌连同到期日期等映射回后端的用户，那么它的生成方式实际上并不重要（除了它不应该是可预测的）。规范没有说明实现细节。

令牌可以是唯一生成的字符串，映射到后端的用户状态，或者您可以将用户信息和到期日期等加密到令牌本身，在这种情况下考虑 SWT。SWT 格式准确定义了您所描述的内容。它包含有关用户、clientId、范围等的明文信息，但还提供了一个加密密钥以使其防篡改。使用共享密钥，即使密钥是在另一台服务器上或由另一方生成的，也可以验证密钥。它们往往会变得相当大，因此不适合传入查询字符串。

有基于云的 STS 解决方案可以为您生成令牌。例如，Azure ACS 可以通过 OAuth2 端点生成 SWT 令牌，并为您管理与刷新令牌、到期日期和授权授予相关的所有状态。您在使用它时节省的精力，您可能会在弄清楚如何与它集成时松懈，但它非常整洁。

于 2013-02-02T01:12:19.403 回答