authentication - REST 和身份验证变体

Question

我目前正在开发 .net 的 REST 库，我想听听一些关于我的开放点的意见:REST 和身份验证。

以下是与该库一起使用的 RESTful 接口(interface)的示例:

[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);
}

服务器代码只需实现该接口(interface)，客户端可以通过工厂获取相同的接口(interface)。或者，如果客户端不使用该库，标准 HTTP 请求也可以工作。

我知道有使用 HTTP 基本身份验证或向需要经过身份验证的用户的请求发送 token 的主要方法。

第一种方法(HTTP 基本身份验证)存在以下问题(部分特定于 Web 浏览器):

• 每次请求都会传输密码 - 即使使用 SSL，这也会给人一种“不好的感觉”。
• 由于密码是通过请求 header 传输的，因此本地攻击者很容易查看传输的 header 来获取密码。
• 密码存储在浏览器内存中。
• 没有使用户“ session ”过期的标准方法。
• 使用浏览器登录会中断页面​​的外观。

第二种方法的问题更集中在实现和库的使用上:

• 每个需要身份验证的请求 URI 都必须有一个 token 参数，这非常重复。
• 如果每个方法实现都需要检查 token 是否有效，则需要编写更多代码。
• 界面将变得不那么具体，例如[RestGet("/get/{id}")] 与 [RestGet("/get/{id}/{token}")]。
• 将 token 放在 URI 末尾的什么位置？根后？其他地方？

<小时/>

我的想法是将 token 作为参数传递给 URL，例如 http:/server/user/get/1234?token=token_id。

另一种可能性是将参数作为 HTTP header 发送，但我猜这会使普通 HTTP 客户端的使用变得复杂。

token 将作为每个请求的自定义 HTTP header (“X-Session-Id”)传回客户端。

这可以完全从接口(interface)中抽象出来，任何需要身份验证的实现都可以只询问 token (如果给定)属于哪个用户。

您认为这会过于违反 REST 还是您有更好的想法？

Answer 1

我倾向于认为身份验证详细信息属于 header ，而不是 URI。如果您依赖于放置在 URI 上的 token ，则应用程序中的每个 URI 都需要进行编码以包含该 token 。它还会对缓存产生负面影响。 token 不断变化的资源将无法再被缓存。与资源相关的信息属于 URI，而不是与应用程序相关的数据(例如凭据)。

看来您必须将网络浏览器作为客户端？如果是这样，您可以使用 HTTP Digest access authentication 进行调查或向客户端颁发自己的 SSL 证书以唯一地识别和验证它们。另外，我不认为 session cookie 一定是坏事。尤其是在必须处理浏览器时。只要您隔离 cookie 处理代码并使应用程序的其余部分不依赖它就可以了。关键只是在 session 中存储用户的身份，没有其他。不要滥用服务器端 session 状态。

如果您的目标客户不是浏览器，那么您可以采取多种方法。我很幸运地使用了亚马逊的S3 Authentication机制。

当然，这都是非常主观的。纯粹性和严格遵循 REST 有时可能是不切实际的。只要您最大限度地减少并隔离此类行为，应用程序的核心仍然可以是 RESTful。我强烈推荐RESTful Web Services作为 REST 信息和方法的重要来源。