我们有许多客户使用我们的 API 来支持他们的网站。
我在工作中开始讨论如何使用 OAuth 进行经过身份验证的 API 调用。 我们将同时拥有两条腿和三条腿。
对于三足流，我们还没有就如何存储访问令牌和秘密达成共识。
解决此问题的常用方法是让客户端将访问令牌和机密存储在自己的数据库中，但这是不可能的，因为客户端不想处理代码更改和实现问题。
我们正在考虑的其他选项：
1) 将访问令牌和秘密保存在 cookie 中
2) 将它们保存在会话中。
我不确定这是否是个好主意。有人有什么建议吗？
谢谢。
【问题讨论】：
标签： php oauth storage access-token
我假设您谈论的是典型的“服务提供商”、“消费者”和“用户”类型的设置。如果您的消费者（客户端）拒绝进行任何更改，我不知道您是否能够实施三足 oAuth。
会话和 cookie 可用于保存令牌，但问题是需要保存令牌的是您的消费者（您的客户），而不是您。对 API 的调用发生在后端，因此在该范围内没有可用的真正会话或 cookie。如果您只是进行 JavaScript 调用，也许这确实有效，但即便如此，通常也是通过代理进行调用，以免出现跨域脚本问题。
在任何一种情况下，如果令牌存储在会话或 cookie 中，它们将是“临时”密钥，并且用户必须在会话或 cookie 过期时重新进行身份验证。但就 oAuth 规范而言，这并没有错——只要用户不介意重新进行身份验证。
【讨论】：
关于1）将访问令牌和秘密保存在cookie中
考虑您的客户在网吧中，在他不清除 cookie 并且下一个人复制此信息后会发生什么？
我会参加 DB 或 PHP 会话
【讨论】：
我在实现 3-legged oauth 时遇到了同样的问题。我在 Google App Engine 上在线申请并使用 Google DataStore 存储访问令牌。
但是，配额是提到here 用于存储数据和引发查询！这是使用 Google App Engine 时的唯一限制！
【讨论】：
正如 Jason 所提到的，如果消费者应用程序不存储身份验证所需的令牌，就不可能发出经过身份验证的请求 - 他们可以以任何他们想要的方式存储它们，但这是等式的必要部分。它可以是文件系统、内存缓存、数据库、内存。
我看到使用 cookie 存储这些的唯一方法是消费者应用程序将这些令牌凭据设置为用户浏览器中的 cookie，并且用户在每次请求时将它们发送回消费者 - 但这似乎很荒谬首先，消费者应用程序将再次需要对其代码进行更改以处理此问题，其次，令牌和令牌密钥将冗余地在网络和用户的浏览器中飞来飞去，如果用户自己决定这样做，这可能是一个安全漏洞黑客攻击。
【讨论】：