设计（OAuth2）访问令牌

Question

我们计划实施OAuth2规范并正在审查“访问令牌”实施。 貌似规范给出了一个很大的自由去实现者，我们正在寻找 的一些最佳做法：

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

到目前为止，我们确定了以下字段：

• 用户识别
• 截止日期
• 版本（这样我们就可以改变未来的格式）
• 客户标识符（即应用程序谁请求令牌）

一些额外的属性（例如。密码散列）将被存储在数据库中，并在 认证期间（使用令牌中的字段作为“密钥”）进行查找。

1. 如何保护它？

我们倾向于安全地签署访问令牌（HMAC），以便我们知道它是否被篡改。 令牌中的字段随后可供所有人阅读。

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

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

感谢， 彼得

Answer 1

只要你可以映射访问令牌你在后台发出回用户与到期日一起等，那么它其实并不重要它是如何产生的（除了那个以外不应该是可预测的）。该规范没有指定实现细节。

令牌可以是映射到后端用户状态的唯一生成的字符串，也可以将用户信息和过期日期等加密到令牌本身中，在这种情况下考虑SWT。 SWT格式完全定义你描述的内容。它包含有关用户，clientId，范围等明文内容的信息，但随后还提供了一个加密密钥以使其防篡改。有了共享密钥，即使是在另一台服务器上或另一方产生密钥，也可验证该密钥。他们往往会变得非常大，所以不理想的传递查询字符串。

有一些基于云的STS解决方案可以为您生成令牌。例如，Azure ACS可以通过OAuth2端点生成SWT令牌，并管理与刷新令牌，到期日期和授权授权相关的所有状态。你在使用它的过程中所节省的成本，你可能会忽略如何与它整合，但它很整洁。