security - 设计 (OAuth2) 访问 token

Question

我们计划实现 OAuth2 规范，并正在审查“访问 token ”实现。
看起来规范给了实现者很大的自由，我们正在寻找
对于一些最佳实践:

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

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

用户标识符

有效期

版本(以便我们将来可以更改格式)

客户端标识符(即请求 token 的应用程序)

一些附加属性(例如密码哈希)将存储在数据库中并在
身份验证(使用 token 中的字段作为“ key ”)。

如何保障？

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

另一种方法是对整个内容进行加密 (AES) 并使其对用户完全不透明。这使得
它要大得多(以字节计)。看起来 FB 现在正在使用加密 token (http://developers.facebook.com/blog/post/572/)

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

谢谢，
彼得

Answer 1

只要您可以将您发布的访问 token 与到期日期等一起映射回后端的用户，那么它的生成方式实际上并不重要(除了它不应该是可预测的)。规范没有说明实现细节。

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

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