RESTAPI登录模式

我正在创建一个restapi，严格遵循apigee的建议，使用名词而不是动词，将api版本烘焙到url中，每个集合有两个api路径，GET-POST-PUT-DELETE用法，等等

我正在开发登录系统，但不确定登录用户的正确休息方式。我现在不是在研究安全性，只是在研究登录模式或流程。（稍后我们将添加2步oAuth，以及HMAC等）

可能的选择

• 类似于

  https://api...com/v1/login.json

• 类似于

  https://api...com/v1/users.json

• 一些我没有想到的事情

---

什么是适合登录用户的REST风格？

REST理念的一个重要部分是在设计API时尽可能多地利用HTTP协议的标准功能。将这一理念应用于身份验证，客户端和服务器将利用API中的标准HTTP身份验证功能

登录屏幕对于人类用户用例非常有用：访问登录屏幕，提供用户/密码，设置cookie，客户端在所有未来请求中提供cookie。使用web浏览器的人不能期望在每个HTTP请求中提供用户id和密码

---

但对于RESTAPI，登录屏幕和会话cookie并不是绝对必要的，因为每个请求都可以包含凭据，而不会影响人类用户；如果客户在任何时候都不合作，则会给出

401

未经授权的响应。描述HTTP中的身份验证支持

TLS（HTTPS）也是一个选项，它允许在每个请求中通过验证另一方的公钥将客户端身份验证给服务器（反之亦然）。此外，这还为奖金渠道提供了保障。当然，要做到这一点，必须在通信之前交换密钥对。（注意，这特别是关于使用TLS识别/验证用户。使用TLS/Diffie Hellman保护通道始终是一个好主意，即使您不通过用户的公钥识别用户。）

---

例如：假设OAuth令牌是您的完整登录凭据。一旦客户机拥有OAuth令牌，就可以在每个请求的标准HTTP身份验证中将其作为用户id提供。服务器可以在第一次使用时验证令牌，并将检查结果与每次请求更新的生存时间一起缓存。任何需要验证的请求如果未提供，将返回

401

。

TL；DR每个请求的登录不是实现API安全所必需的组件，身份验证是必需的

如果不谈一般的安全性，很难回答您关于登录的问题。对于某些身份验证方案，没有传统的登录方式

REST并没有规定任何安全规则，但实际上最常见的实现是带有3路身份验证的OAuth（正如您在问题中提到的）。本质上没有登录，至少每个API请求都没有。使用3路身份验证，您只需使用令牌

用户批准API客户端并授予以长寿命令牌形式发出请求的权限

Api客户机通过使用长寿命令牌获得短命令牌

Api客户机随每个请求发送短期令牌

此方案允许用户随时撤销访问权限。实际上，我见过的所有公开可用的RESTful API都使用OAuth来实现这一点

我只是不认为您应该在登录方面提出您的问题，而是考虑总体上保护API

有关REST API身份验证的更多信息，请参阅以下参考资料：

，即所有REST术语的工作顺序，包含客户机-服务器交互的定义：

所有REST交互都是无状态的。也就是说，每个请求都包含 连接器了解以下内容所需的所有信息： 请求，独立于之前的任何请求

此限制可实现四项功能，第一项和第三项在这种特殊情况下很重要：

• 第一：它消除了连接器保持应用状态的任何需要 在请求之间，从而减少物理资源的消耗 提高可扩展性
• 第三：它允许中间人单独查看和理解请求， 当服务被动态地重新安排时，这可能是必要的

现在让我们回到你的安全案例。每个请求都应该包含所有必需的信息，授权/身份验证也不例外。如何做到这一点？每一个请求都会通过电线发送所有需要的信息

其中一个例子就是如何将其原型化。实际上，这意味着向每个请求添加当前消息的哈希代码。由加密哈希函数与秘密密钥组合计算的哈希代码。加密哈希函数是预定义的，或者是按需代码REST概念的一部分（例如JavaScript）。服务器应该向客户端提供秘密密钥作为资源，客户端使用它来计算每个请求的哈希代码

HMAC实现的例子很多，但我希望您注意以下三个：

它在实践中是如何工作的 如果客户机知道密钥，那么就可以使用资源进行操作。否则，他将被临时重定向（状态代码307临时重定向）以授权和获取密钥，然后重定向回原始资源。在这种情况下，不需要事先知道（例如，在某个地方硬编码）授权客户端的URL是什么，并且可以对此进行调整