【问题标题】:How to design a RESTful API to check for user's credentials?如何设计一个 RESTful API 来检查用户的凭据?
【发布时间】:2012-04-26 01:38:41
【问题描述】:

我正在为移动应用程序设计一个 API,我希望它保持 RESTful。
API 是使用 Basic HTTP Auth 授权的,但是,当用户第一次打开应用程序时,他需要先登录,所以我需要设计一个 API 来检查用户的凭据,它将接受一对用户名和密码,相应地返回成功或失败。
问题是网址应该是什么所以它很安静?我认为 /login 不是一个好方法。

【问题讨论】:

    标签: rest


    【解决方案1】:

    通过 HTTP GET 请求传递敏感数据通常被视为不好的做法。

    密码信息是敏感数据,是违反idempotent operations 应为GET 请求规则的例外情况之一。

    为什么这是一个例外?浏览器历史和服务器日志将存储GET 请求。这意味着此敏感信息在两个地方都以纯文本形式显示。因此,如果有人掌握了其中任何一个 - 那么该信息现在就在他们手中。

    您应该使用 HTTP POST 请求将此敏感信息传递给 RESTful API,因为浏览器不会存储它们,服务器也不会记录它们。但是,第一道防线是使用安全 HTTP (HTTPS) 来确保这些信息不受外来者的影响。

    因此,将 HTTP 请求的 正文 中的此信息传递给 HTTPS URL。

    【讨论】:

      【解决方案2】:

      一个好的方法是对当前用户的帐户/个人资料信息执行GET 请求。并让它返回用户名、设置、头像 url 等。me 是常用的身份验证用户的简写标识符。

      GET https://api.example.com/profiles/me
      HTTP/1.1 200 OK
      {
        "username": "bob",
        "id": "xyz",
        "created_at": 123,
        "image_url": "https://example.com/bob.png"
      }
      

      【讨论】:

        【解决方案3】:

        来自维基百科:

        客户端-服务器通信进一步受到没有客户端的限制 在请求之间存储在服务器上的上下文。每个请求来自 任何客户都包含服务所需的所有信息 请求,并且任何会话状态都保存在客户端中。

        因为服务器不存储来自客户端的会话状态,所以您的 API 不应公开任何登录/注销功能:在每个请求中,您应该发送用户凭据,并且服务器每次都应该验证它们.

        检查this discussion in SO,它阐明了这个概念。

        【讨论】:

          【解决方案4】:

          我同意 Carlos 的观点 - 在普通的 restful API 中,没有会话,因此您无法进行一次身份验证然后重用会话,您实际上需要在每次调用时传递凭据集(不理想)。

          在这种情况下,听起来您最好使用其中一个 openAuth (http://www.oAuth.net) - 这通过在应用程序首次运行时进行身份验证然后生成访问令牌以允许访问来工作在每次调用中(+一个刷新令牌)。

          (您可能会争辩说访问令牌是状态 - 它有点像 - 但是,至少它通常寿命明显更长)。

          【讨论】:

          • 是的,我在每次通话时都会通过设置的凭据,但是,当用户第一次打开应用程序时,我确实需要登录来检查用户的凭据
          • 实际上,我没有保留会话 cookie 或类似的东西
          • 好的 - 所以我猜你必须在每次调用时传递凭据 username / password 是正确的。您要么需要始终通过它,要么通过它一次并跟踪会话。
          【解决方案5】:

          GET https://api.example.com/auth

          设置了授权标头。

          【讨论】:

            猜你喜欢
            • 2012-05-19
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2019-11-26
            • 2015-03-17
            • 2017-10-03
            • 2015-05-14
            • 1970-01-01
            相关资源
            最近更新 更多