如何在RESTfulAPI中使用OpenID?

我现在花了一些时间研究这些选择,并想总结一下这些发现。 首先,稍微多一些上下文——我开发和控制服务和API使用者。消费者是基于Flash的应用程序,它是从API现在所在的主机提供服务的,并且应该在浏览器中使用。目前还没有第三方客户。

所以这个问题可以分为两部分,

• 如何通过API进行OpenID身份验证
• 如何在后续请求中保持“已验证”状态

对于第一部分,OpenID认证几乎总是包含交互式步骤。在身份验证过程中,很可能会有一个步骤,用户在OpenID提供者的网页中,登录并按下“我同意”按钮。因此,API不能也不应该透明地处理这个问题(没有“告诉我你的OpenID提供者和密码,我会做其余的事情”)。它能做的最好的事情就是前后传递HTTP链接,客户机必须打开这些链接并按照说明进行操作。

保持“认证”状态

RESTAPI应该是无状态的,每个请求都应该包含处理它所需的所有信息,对吗?对于每个请求,使用OpenID提供者进行身份验证没有任何意义,因此 一些 这种会议是必要的。用于通信会话密钥(或“访问令牌”或用户名/密码)的一些选项包括:

• HTTPS+基本身份验证(每个请求中的“授权:基本…”头)
• 签名请求 Amazon-style (授权:AWS…)每个请求中的标题)
• OAuth:获取访问令牌,在每个请求中包含该令牌和一系列其他参数
• 存储会话密钥的cookie(“cookie:…”每个请求中的标题)
• 在cookie本身中存储会话信息的签名cookie

现在只有一个API使用者,所以我选择了最简单的可能工作的东西——cookies。它们在塔架上非常容易使用,借助于 Beaker . 它们在Flash应用程序中也“只是工作”——因为它在浏览器中运行,浏览器会在Flash应用程序发出的请求中包含相关的cookie——应用程序完全不需要对此进行更改。这里有一个StackOverflow问题,它也提倡使用cookie: RESTful authentication for web applications

烧杯也有很好的特点 cookie-only sessions 其中所有会话数据都包含在cookie本身中。我想这差不多是无状态的。有 不 服务器上的会话存储。cookie是签名的,并且可以选择加密,以避免在客户端篡改它们。缺点是cookie会变得更大一点,因为它现在需要存储的不仅仅是会话密钥。通过删除一些我在会话中不需要的东西(来自OpenID身份验证的剩余部分),我把cookie的大小降到了大约200字节。

OAuth 更适合API使用。下面是在Python中使用的OAuth示例: oauth-python-twitter . Leah Culver python-oauth 库是Python中OAuth的规范实现,但是 python-oauth2 是最近的一个竞争对手,正在引起轰动。至于灵感, django-piston 支持在为Django创建RESTfulAPI时使用OAuth进行身份验证,尽管文档不如我对特定主题所希望的那样好。

如果您构建API,您可以检查OAuth协议。它是OpenID的补充。