设计（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令牌，并管理与刷新令牌，到期日期和授权授权相关的所有状态。你在努力使用它时节省了多少，你可能会在弄清楚如何与它集成时放松，但它非常整洁。