如何在 RESTful API 中使用 OpenID? [英] How to use OpenID in RESTful API?

问题描述

我正在使用 RESTful API 构建基于 Pylons 的 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 提供商的网页中，登录并按下我同意"按钮.所以 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 + BASIC 身份验证(每个请求中的授权:基本 ..."标头)
• 签署请求 亚马逊风格(每个请求中的授权:AWS ..."标头)
• OAuth:获取访问令牌，在每个请求中包含该令牌和一堆其他参数
• 存储会话密钥的 Cookie(每个请求中的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 使用者，所以我选择了可​​能可行的最简单的东西——cookie.在 Beaker 的帮助下，它们非常容易在 Pylons 中使用.它们也在 Flash 应用程序中正常工作"——因为它在浏览器中运行，浏览器将在 Flash 应用程序发出的请求中包含相关的 cookie——应用程序根本不需要就此进行更改.这里有一个 StackOverflow 问题也提倡使用 cookie:Web 应用程序的 RESTful 身份验证

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

Beaker 还具有 cookie-only session 的出色功能，其中所有会话数据都包含在 cookie 本身中.我想这几乎是无状态的.服务器上没有会话存储.Cookie 已签名并可选择加密，以避免在客户端篡改它们.缺点是 cookie 变得有点大，因为它现在需要存储的不仅仅是会话密钥.通过删除一些我在会话中并不真正需要的东西(OpenID 身份验证的剩余部分)，我将 cookie 大小降低到大约 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.

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