如何使用OpenID的REST风格的API？ [英] How to use OpenID in RESTful API?

问题描述

我构建REST风格的API，它目前缺乏任何认证塔基于Web应用程序。所以我要去实施，为了避免所有的麻烦和谨慎与存储用户密码，我想使用的OpenID进行身份验证。什么是做到这一点的最好方法是什么？有这两样东西兼容吗？是否有使用OpenID的，我可以从灵感现有的REST API的？

I'm building Pylons-based web application with RESTful API, which currently lacks any authentication. So I'm going to implement that and in order to avoid all the trouble and caution with storing user passwords, I'd like to use OpenID for authentication. What would be the best way to do this? Are these two things compatible? Are there existing REST APIs that use OpenID that I can take inspiration from?

推荐答案

现在我花了一些时间来研究的选项，想总结的结果。
首先，多一点点背景 - 我发展，同时控制服务和API消费国。消费者是基于Flash的应用程序，是由同一主机的API现在供应，应该在浏览器中使用。看不到第三方客户端呢。

I've now spent some time researching the options and would like to summarize the findings. First, a little bit more context -- I develop and control both the service and API consumer. Consumer is Flash-based app that is served from the same host the API is now and is supposed to be used in browser. No third party clients in sight yet.

所以，问题可以分为两部分划分，

So the question can be divided in two parts,

• 如何通过API做的OpenID认证


• 如何保持后续请求的验证状态

有关第一部分，OpenID身份验证的几乎总是包括交互式步骤。在认证过程中存在很可能将是一个步骤，其中用户在OpenID提供商的网页，登录和pressing一些我同意按钮。所以API能够，也不应该透明地处理这个（没有告诉我你的OpenID提供商和密码，我会做休息）。最好是可以做的是通过提出和客户端打开，并按照指示回HTTP链接。

For first part, OpenID authentication almost always includes interactive steps. During the authentication process there will most likely be a step where user is in OpenID provider's web page, signing in and pressing some "I agree" button. So API cannot and shouldn't handle this transparently (no "tell me your OpenID provider and password and I'll do the rest"). Best it can do is pass forth and back HTTP links that client has to open and follow instructions.

维护验证状态

REST API的应该是无状态的，每个请求应包括处理一下，右所需的所有信息？它不会作出任何意义对OpenID提供商为每个请求进行认证，所以的部分的一种会话时，只需要。一些对通信会话密钥（或访问令牌或用户名/密码）的选项是：

REST APIs should be stateless, each request should include all the information needed to handle it, right? It wouldn't make any sense to authenticate against OpenID provider for each request, so some kind of session is neccessary. Some of the options for communicating session key (or "access token" or username/password) are:

• HTTPS +基本身份验证（授权：基本...在每个请求头）


• 签名请求<一个href=\"http://docs.amazonwebservices.com/AmazonS3/2006-03-01/dev/index.html?RESTAuthentication.html\">Amazon-style （授权：AWS ......在每个请求头）


• 的OAuth：获得访问令牌，包括在每个请求一堆其他参数


• 的Cookie存储会话密钥（曲奇：......在每个请求头）


• 签名的cookie，在cookie自身
存储会话信息

• HTTPS + BASIC authentication ("Authorization: Basic ..." header in each request)
• Signing requests Amazon-style ("Authorization: AWS ... " header in each request)
• OAuth: acquire Access Token, include that and a bunch of other parameters in each request
• Cookie that stores session key ("Cookie: ... " header in each request)
• Signed cookie that stores session information in the cookie itself

有只有一个API的消费者，现在，所以我选择了去为可能会工作的最简单的事情 - 饼干。他们是超级容易塔使用，具有烧杯的帮助。他们还只是工作中的Flash应用程序 - 因为它里面运行的浏览器中，浏览器将包括在Flash应用程序，使有关的请求饼干 - 应用程序并不需要与有关，在一切都变了。这里有一个计算器疑问，还倡导使用Cookie：<一href=\"http://stackoverflow.com/questions/1137977/restful-authentication-for-web-applications\">RESTful Web应用程序的认证

There's just one API consumer right now, so I chose to go for simplest thing that could possibly work -- cookies. They are super-easy to use in Pylons, with help of Beaker. They also "just work" in the Flash app -- since it runs inside browser, browser will include relevant cookies in the requests that Flash app makes -- the app doesn't need to be changed at all with respect to that. Here's one StackOverflow question that also advocates using cookies: RESTful authentication for web applications

烧杯也有唯一cookie的会话的不错的功能，所有的会话数据都包含在cookie自身。我想这大约是无状态的，因为它得到。还有的没有的会议服务器存储。 Cookies是签名和加密可选，以避免在客户端与他们篡改。其缺点是，Cookie会大一点，因为它现在需要存储的不仅仅是会话密钥多。通过消除一些东西，我并不真的需要在会话（来自OpenID身份验证的剩菜）我有饼干大小下降到约200个字节。

Beaker also has nice feature of cookie-only sessions where all session data is contained in the cookie itself. I guess this is about as stateless as it gets. There is no session store on server. Cookies are signed and optionally encrypted to avoid tampering with them in client side. The drawback is that cookie gets a bit bigger, since it now needs to store more than just session key. By removing some stuff I didn't really need in the session (leftovers from OpenID authentication) I got the cookie size down to about 200 bytes.

这篇关于如何使用OpenID的REST风格的API？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！