【问题标题】:How to format header WWW-Authenticate when authentication fails身份验证失败时如何格式化标头 WWW-Authenticate
【发布时间】:2014-03-21 15:21:52
【问题描述】:

我正在实现一个 REST API,它还提供了对用户进行身份验证的功能。身份验证要求用户发送 POST 请求,正文中包含以下数据:

{
  "userOrEmail": "spook",
  "passowrd": "Test1234"
}

如果用户名和密码匹配,用户从服务器取回一个令牌,如果不匹配,服务器返回 401 Unauthorized,并带有以下标头:

WWW-Authenticate: Credentials realm="http://localhost:9000/auth/users/credentials"

这个标题可以接受吗? realm 包含用户可以尝试再次验证的位置。

【问题讨论】:

    标签: http rest authentication


    【解决方案1】:

    这似乎是可以接受的,但可能不是最佳的,除非在非常特殊的条件下。来自RFC1945

    领域值(区分大小写)与被访问服务器的规范根 URL 相结合,定义了保护空间。这些领域允许将服务器上的受保护资源划分为一组保护空间,每个保护空间都有自己的身份验证方案和/或授权数据库。领域值是一个字符串,通常由源服务器分配,它可能具有特定于身份验证方案的附加语义。

    所以,你可以,但我可能对使用相同身份验证的多个应用程序以及如果它们共享相同的域名会无意中交叉身份验证感到偏执。为了安全起见,最好通过应用程序隔离领域。

    【讨论】:

    • 是的...我也看到了 RFC1945。所以这样的事情会更好吗? WWW-Authenticate:基本领域="api"。我发现为领域确定合适的值有点困难......
    • 我的理解是,传统是您的应用程序的名称,因此您服务器上的其他任何人都不会混淆它。为了结合您的想法,您可以将应用程序名称填充到该 URL 中并获得(类似)两全其美。
    • 最后一个问题... URL 应该是绝对的还是相对于 RFC1945 所述的正在访问的服务器的规范根 URL 的相对地址?
    • RFC 似乎并不关心。那么,为了您的通知目的,我会说使用整个 URL。
    【解决方案2】:

    不,这是不可接受的。

    a) 没有称为“凭据”的身份验证方案。

    b) “realm”参数的用途不同。

    【讨论】:

      猜你喜欢
      • 2015-01-10
      • 1970-01-01
      • 1970-01-01
      • 2018-04-13
      • 2016-03-21
      • 2011-05-15
      • 2017-03-19
      • 1970-01-01
      • 2015-12-25
      相关资源
      最近更新 更多