REST和认证变种 [英] REST and authentication variants

问题描述

我目前工作的一个REST库.NET和我想听到一个开放的时候，我有一些意见：REST和认证

I am currently working on a REST library for .net, and I would like to hear some opinions about an open point I have: REST and authentication.

下面是图书馆使用的RESTful接口的例子：

Here is an example of an RESTful interface used with the library:

[RestRoot("/user")]
public interface IUserInterface
{
  [RestPut("/")]
  void Add(User user);

  [RestGet("/")]
  int[] List();

  [RestGet("/get/{id}")]
  User Get(int id);

  [RestDelete("/delete/{id}")]
  void Delete(int id);
}

服务器code，则只是实现接口和客户端可以通过工厂获得相同的接口。或者，如果客户端不使用该库的标准的HTTP请求也适用。

The server code then just implements the interface and the clients can obtain the same interface through a factory. Or if the client is not using the library a standard HTTP request also works.

我知道有或者使用HTTP基本认证或发送令牌需要身份验证的用户请求的主要途径。

I know that there are the major ways of either using HTTP Basic Auth or sending a token to requests requiring authenticated users.

第一种方法（HTTP基本验证），有以下问题（部分web浏览器专用）：

The first method (HTTP Basic Auth), has the following issues (partly web browser specific):

• 的口令都与每个请求传输 - 即使SSL这有某种不好的预感
。

• 由于密码与请求头发送的，它会很容易为本地攻击者看发射头获得的密码。


• 的密码是在浏览器中的可用内存。


• 没有标准的方式来终止用户的会话。


• 登录的浏览器中断一个页面的外观和感觉。

第二个方法的问题是更侧重于实施和库的使用：

The issues for the second method are more focused on implementation and library use:

• 每个请求的URI，需要认证必须有令牌，这只是很重复的参数。


• 有很多更code如果每个方法的实现需要检查，如果令牌是有效的写了。


• 界面将变得不那么具体如 [RestGet（/获取/（编号））] 与 [RestGet（/获取/ {ID} / {令牌}） ] 。


• 如果把令牌：在URI的结束？后根？别的地方？

我的想法是令牌作为参数传递到像网址 HTTP：？/服务器/用户/获得/ 1234记号= token_id

My idea was to pass the token as parameter to the URL like http:/server/user/get/1234?token=token_id.

另一种可能性是将参数的形式发送HTTP头，但这将使用与普通的HTTP客户端我猜复杂化。

Another possibility would be to send the parameter as an HTTP header, but this would complicate usage with plain HTTP clients I guess.

该令牌会得到传回给客户端在每次请求自定义HTTP标头（X-会话ID）。

The token would get passed back to the client as a custom HTTP header ("X-Session-Id") on each request.

这则可以完全从抽象的接口，并执行任何需要身份验证可能只是问哪个用户令牌（如果有）属于

This then could be completely abstracted from the interface, and any implementation needing authentication could just ask which user the token (if given) belongs to.

你认为这会违反REST太多，或你有什么更好的想法？

Do you think this would violate REST too much or do you have any better ideas?

推荐答案

我倾向于认为，认证的细节在标题中，而不是URI的归属。如果你依赖于令牌被放置在URI，然后每URI在你的应用程序将需要连接$ C $光盘包含令牌。它也将产生不利的缓存影响。用令牌是不断变化将不再能够资源被缓存。资源相关的信息所属的URL，而不是应用程序相关的数据，例如凭据。

I tend to believe that authentication details belong in the header, not the URI. If you rely on a token being placed on the URI, then every URI in your application will need to be encoded to include the token. It would also negatively impact caching. Resources with a token that is constantly changing will no longer be able to be cached. Resource related information belongs in the URI, not application related data such as credentials.

看来你必须作为客户端针对Web浏览器？如果是这样你可以调查使用 HTTP摘要访问认证或客户发出自己的SSL证书唯一标识和验证他们的身份。另外，我不认为会话cookie都未必是一件坏事。尤其是必须处理的浏览器时。只要你隔离cookie处理code，使应用程序的其余部分不能依赖它，你将被罚款。关键是只存储了用户的会话身份，没有别的。不要滥用服务器端会话状态。

It seems you must be targeting web browsers as a client? If so you could investigate using HTTP Digest access authentication or issuing clients their own SSL certificates to uniquely identify and authenticate them. Also, I don't think that session cookies are necessarily a bad thing. Especially when having to deal with a browser. As long as you isolate the cookie handling code and make the rest of the application not rely on it you would be fine. The key is only store the user's identity in the session, nothing else. Do not abuse server side session state.

如果你的目标浏览器以外的客户，然后也有一些你可以采取的办法。我有运气使用亚马逊的<一个href=\"http://docs.amazonwebservices.com/AmazonCloudFront/latest/DeveloperGuide/index.html?RESTAuthentication.html\"标题=Amazon S3的验证> S3认证机制。

If you are targeting clients other than the browser then there are a number of approaches you can take. I've had luck with using Amazon's S3 Authentication mechanism.

这是所有非常主观的，当然。纯度和以下REST的信有时是不切实际的。只要你最小化和隔离这样的行为，你的应用程序的核心仍然可以REST风格。我强烈建议 REST Web服务作为REST的信息和方法的重要来源。

This is all very subjective of course. Purity and following REST to the letter can sometimes be impractical. As long as you minimize and isolate such behavior, the core of your application can still be RESTful. I highly recommend RESTful Web Services as a great source of REST information and approaches.

这篇关于REST和认证变种的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！