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