OAuth:存储访问令牌和密钥
我们有许多客户使用我们的API来支持他们的网站。
我在工作中开始了关于使用OAuth进行身份验证API调用的对话。我们将会有两条腿和三条腿的流。
对于三条腿的流，我们仍然没有就如何存储访问令牌和密钥达成共识。
解决此问题的常见方法是让客户端将访问令牌和密码存储在自己的数据库中，但这是不可能的，因为客户端不想处理代码更改和实现问题。
我们正在考虑的其他选择：
1)将访问令牌和密钥保存在cookie中
2)将它们保存在会话中。
我不确定这两个是不是一个好主意。有人有什么建议吗？
谢谢。
回答 4
Stack Overflow用户
发布于 2010-08-04 07:37:27
我假设你说的是典型的“服务提供商”、“消费者”和“用户”类型的设置。如果您的消费者(客户端)拒绝进行任何更改，我不知道您是否能够实现三条腿的oAuth。
会话和cookie可以用来保存令牌，但问题是需要保存它们的是您的消费者(您的客户端)，而不是您。对API的调用发生在后端，因此在该作用域中没有可用的实际会话或cookie。如果您只进行JavaScript调用，也许这确实可以工作，但即使这样，为了避免跨域脚本问题，通常也会通过代理进行调用。
在这两种情况下，如果令牌存储在会话或cookies中，则它们将是“临时”密钥，当会话或cookies过期时，用户必须重新进行身份验证。但就oAuth规范而言，这并没有什么错--只要用户不介意重新进行身份验证。
Stack Overflow用户
发布于 2010-08-18 20:06:56
正如Jason提到的，如果消费者应用程序不存储身份验证所需的令牌，那么它们就不可能发出身份验证请求-它们可以以任何想要的方式存储它们，但这是等式中需要的一部分。它可以是文件系统、memcache、数据库、内存。
我看到的使用cookie存储这些信息的唯一方法是，消费者应用程序将这些令牌凭据设置为用户浏览器中的cookie，并且用户在每次请求时将它们发送回消费者--然而，这看起来很荒谬，因为首先，消费者应用程序将再次需要对其代码进行更改以处理此问题，其次，令牌和令牌密钥将冗余地在网络和用户浏览器中飞行，如果用户自己决定进行黑客攻击，这可能是一个安全漏洞。
Stack Overflow用户
发布于 2011-02-04 17:51:56
我在实现3条腿的oauth时也遇到了同样的问题。我在Google App Engine上线了我的应用程序，并使用谷歌DataStore来存储访问令牌。
然而，配额是指用于存储数据和抛出查询的here！这是使用Google App Engine时的唯一限制！
https://stackoverflow.com/questions/3284260
复制相似问题