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