2010-07-19 194 views
19

我们有许多客户使用我们的API来为他们的网站提供动力。OAuth:存储访问令牌和秘密

我已经开始使用OAuth进行经过身份验证的API调用的对话。 我们将拥有两条腿和三条腿。

对于三足式流程,我们还没有就如何存储访问令牌和秘密达成共识。

这个问题的常见方法是让客户端将访问令牌和秘密存储在他们自己的数据库中,但这是不可能的,因为客户端不想处理代码更改和实现问题。

其他选项,我们正考虑:

1)保存访问令牌和秘密在会话保存他们的cookie

2)。

我不确定这些是否是一个好主意。有没有人有什么建议?

谢谢。

+0

我个人不敢使用会话/ Cookie出于安全原因,因为这是访问令牌的情况:( – 2011-02-04 09:53:48

回答

13

我假设你正在谈论典型的“服务提供商”,“消费者”和“用户”类型的设置。如果您的消费者(客户)拒绝做出任何更改,我不知道您是否能够实施三方oAuth。

会话和cookie可用于保存令牌,但问题在于它是您的客户(您的客户)需要保存它们 - 而不是您。对您的API的调用发生在后端,因此在该范围内没有可用的会话或cookie。如果您只是进行JavaScript调用,也许这确实起作用,但即使这样,通常通过代理进行调用,以避免跨域脚本问题。

在这两种情况下,如果令牌存储在会话或cookie中,它们将是“临时”密钥,当会话或cookie过期时,用户将不得不重新验证身份。但就oAuth规范而言,只要用户不介意重新进行身份验证,就没有任何问题。

你可以参考Sample app for .NET written using MVC 5 Razor engine

1

贾森提到它不可能为消费者应用程序,以验证请求,如果他们不存储所需的认证令牌 - 他们可以将它们存储在任何他们想要的方式,但这种是等式中需要的一部分。它可以是文件系统,memcache,数据库,内存。

我看到使用cookie来存储这些消息的唯一方法是让消费者应用程序将这些令牌凭证设置为用户浏览器中的cookie,并且用户将它们发送回消费者,但每次请求都会发生这种情况 - 但这看起来很荒唐首先,消费者应用程序将再次需要对其代码进行更改以处理此问题;其次,令牌和令牌密钥将冗余地围绕网络和用户的浏览器飞行,如果用户自己决定黑客攻击。

0

当我实施3腿oauth时,我遇到了同样的问题。我使用Google DataStore在Google App Engine &上在线申请我的应用程序以存储访问令牌。

但是,配额提及here用于存储数据&投掷查询!这是使用Google App Engine的唯一限制!

0

约1)保存访问令牌和秘密在cookie

考虑您的客户在一家网吧后他不清晰饼干和旁边的人拷贝这个信息会发生什么?

我会去DB或PHP会话

相关问题