【问题标题】:Standard -server to server- and -browser to server- authentication method标准-服务器到服务器-和-浏览器到服务器-身份验证方法
【发布时间】:2012-11-07 13:37:45
【问题描述】:

我有一些资源的服务器;到目前为止,所有这些资源都是由人类用户通过浏览器请求的,并且使用用户名/密码方法进行身份验证,该方法会生成带有令牌的 cookie(以使会话打开一段时间)。

现在系统要求其他服务器向该资源服务器发出 GET 请求,但它们必须进行身份验证才能获取它们。我们一直在使用授权 IP 列表,但有两种身份验证方法会使代码更加复杂。

我的问题是:

  • 是否有任何标准方法或模式可以使用相同的代码对人类用户和服务器进行身份验证?

  • 如果没有,我现在使用的方法是否正确,或者是否有更好/更标准的方法来完成我的需要?

提前感谢您的任何建议。

【问题讨论】:

    标签: web-services rest authentication web-applications resources


    【解决方案1】:

    我之前在我的 Web 服务中使用了 basic authentication 和 cookie 的组合。在基本身份验证中,您传递在 HTTP 标头中编码的用户名/密码,它看起来像这样。

    Authorization: Basic QWxhZGluOnNlc2FtIG9wZW4=
    

    单词“Basic”后面的字符串是用冒号分隔的编码用户名和密码。 REST API 可以从 HTTP 标头中获取此信息并执行身份验证和授权。如果身份验证失败,我会返回一个 HTTP Unauthorized 错误,如果他们已通过身份验证但未获得授权,我会返回一个 HTTP Forbidden 错误,以区分身份验证失败与授权失败。如果它是 Web 客户端并且此人已通过身份验证,那么我会在 HTTP 标头中通过请求传递以下内容。

    Authorization: Cookie
    

    这告诉 Web 服务从 HTTP 请求中获取 cookie 并将其用于授权,而不是重新进行身份验证过程。

    这将允许非 Web 浏览器的客户端使用相同的技术。客户端始终可以对每个请求使用基本身份验证,或者他们可以对初始请求使用基本身份验证,然后维护 cookie。这种技术也适用于没有单独登录页面的Single Page Applications (SPAs)

    注意:对用户名和密码进行编码不够安全;您仍想使用 HTTPS/SSL 来保护通信通道。

    【讨论】:

      猜你喜欢
      • 2016-05-16
      • 1970-01-01
      • 2017-08-15
      • 2019-07-23
      • 2022-09-27
      • 2022-11-30
      • 2021-04-27
      • 2020-11-24
      • 2019-11-06
      相关资源
      最近更新 更多