首页 文章

REST API登录模式

提问于
浏览 次
164

我正在创建一个REST api，密切关注apigee建议，使用名词不是动词，api版本加入url，每个集合有两个api路径，GET POST PUT DELETE用法等 .

我正在登录系统，但不确定正确的REST方式登录用户 . 我现在不是在处理安全问题，只是登录模式或流程 . （稍后我们将添加2步oAuth，HMAC等）

可能的选择

  • 一个类似于 https://api...com/v1/login.json 的POST

  • 一个像 https://api...com/v1/users.json 的东西

  • 我还没有......

登录用户的正确REST样式是什么？

api rest design-patterns

3 回答

  • 40

    Principled Design of the Modern Web Architecture by Roy T. Fielding and Richard N. Taylor，即所有REST术语的作品序列来自，包含客户端 - 服务器交互的定义：

    所有REST交互都是无状态的 . 也就是说，每个请求都包含连接器理解请求所需的所有信息，与之前可能存在的任何请求无关 .

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

    • 1st：它 removes any need for the connectors to retain application state between requests ，从而减少了物理资源的消耗并提高了可扩展性;

    • 第三：它允许中间人查看和 understand a request in isolation ，这在动态重新安排服务时可能是必要的;

    现在让我们回到您的安全案例 . 每个请求都应包含所有必需的信息，授权/身份验证也不例外 . 怎么做到这一点？每次请求都可以通过电汇直接发送所有必需的信息 .

    如何实现这一目标的一个例子是hash-based message authentication code or HMAC . 实际上，这意味着向每个请求添加当前消息的哈希码 . 通过加密散列函数结合秘密加密密钥计算的散列码 . 加密哈希函数可以是预定义的，也可以是代码按需REST概念的一部分（例如JavaScript） . 秘密加密密钥应由服务器作为资源提供给客户端，客户端使用它来计算每个请求的哈希码 .

    有很多 HMAC 实现的例子，但我希望你注意以下三点：

    它在实践中如何运作

    如果客户端知道密钥，那么它就可以使用资源进行操作了 . 否则，他将被临时重定向（状态码307临时重定向）以授权并获取密钥，然后重定向回原始资源 . 在这种情况下，不需要事先知道（即某处的硬编码）授权客户端的URL是什么，并且可以随时间调整该模式 .

    希望这能帮助您找到合适的解决方案！

    回复于
  • 122

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

    在没有谈论安全性的情况下，很难回答关于登录的问题 . 有了一些身份验证方案，就没有传统的登录方式 .

    REST并未规定任何安全规则，但实际中最常见的实现是具有3向身份验证的OAuth（正如您在问题中提到的那样） . 本身没有登录，至少没有每个API请求 . 使用3向身份验证，您只需使用令牌即可 .

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

    • Api客户端使用长期令牌获取短期令牌 .

    • Api客户端为每个请求发送短期令牌 .

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

    我只是认为你不应该在登录方面构建你的问题（和问题），而是考虑一般地保护API .

    有关REST API身份验证的更多信息，您可以查看以下资源：

    回复于
  • 23

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

    登录屏幕非常适合人类用户使用案例：访问登录屏幕，提供用户/密码，设置cookie，客户端在将来的所有请求中提供该cookie . 不能指望使用Web浏览器的人为每个单独的HTTP请求提供用户ID和密码 .

    但对于REST API，登录屏幕和会话cookie不是绝对必要的，因为每个请求都可以包含凭证而不会影响人类用户;如果客户在任何时候都不合作，可以给出一个 401 "unauthorized"响应 . RFC 2617描述了HTTP中的身份验证支持 .

    TLS（HTTPS）也是一种选择，并且允许通过验证另一方的公钥在每个请求中对客户端进行服务器认证（反之亦然） . 此外，这可以确保渠道获得奖金 . 当然，在通信之前进行密钥对交换是必要的 . （注意，这具体是关于使用TLS识别/验证用户 . 使用TLS / Diffie-Hellman保护 Channels 总是一个好主意，即使您没有通过其公钥识别用户 . ）

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

    回复于

相关问题