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