通过与 Jira 对比,让您更全面了解 PingCode

  • 首页
  • 需求与产品管理
  • 项目管理
  • 测试与缺陷管理
  • 知识管理
  • 效能度量
        • 更多产品

          客户为中心的产品管理工具

          专业的软件研发项目管理工具

          简单易用的团队知识库管理

          可量化的研发效能度量工具

          测试用例维护与计划执行

          以团队为中心的协作沟通

          研发工作流自动化工具

          账号认证与安全管理工具

          Why PingCode
          为什么选择 PingCode ?

          6000+企业信赖之选,为研发团队降本增效

        • 行业解决方案
          先进制造(即将上线)
        • 解决方案1
        • 解决方案2
  • Jira替代方案

25人以下免费

目录

什么是oAuth2协议

OAuth2是一个授权协议。OAuth2.0框架能让第三方应用以有限的权限访问HTTP服务,可以通过构建资源拥有者与HTTP服务间的许可交互机制,让第三方应用代表资源拥有者访问服务,或者通过授予权限给第三方应用,让其代表自己访问服务。

一、oAuth2协议概念

OAuth2是一个授权协议。OAuth2.0框架能让第三方应用以有限的权限访问HTTP服务,可以通过构建资源拥有者与HTTP服务间的许可交互机制,让第三方应用代表资源拥有者访问服务,或者通过授予权限给第三方应用,让其代表自己访问服务。

OAuth2.0是OAuth协议的延续版本,但不向前兼容OAuth 1.0(即完全废止了OAuth1.0)。 OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户,要么允许第三方应用代表用户获得访问的权限。同时为Web应用,桌面应用和手机,和起居室设备提供专门的认证流程。

二、授权模式

1、授权码模式

授权码模式(authorization code)是功能最完整、流程最严密的授权模式。

步骤:

  • 用户访问客户端,后者将前者导向认证服务器,假设用户给予授权,认证服务器将用户导向客户端事先指定的”重定向URI”(redirection URI),同时附上一个授权码。
  • 客户端收到授权码,附上早先的”重定向URI”,向认证服务器申请令牌:GET /oauth/token?response_type=code&client_id=test&redirect_uri=重定向页面链接。请求成功返回code授权码,一般有效时间是10分钟。
  • 认证服务器核对了授权码和重定向URI,确认无误后,向客户端发送访问令牌(access token)和更新令牌(refresh token)。

2、简化模式

简化模式(implicit grant type)不通过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了”授权码”这个步骤,因此得名。所有步骤在浏览器中完成,令牌对访问者是可见的,且客户端不需要认证。

步骤:

  • 客户端将用户导向认证服务器。
  • 用户决定是否给于客户端授权。
  • 假设用户给予授权,认证服务器将用户导向客户端指定的”重定向URI”,并在URI的Hash部分包含了访问令牌。
  • 浏览器向资源服务器发出请求,其中不包括上一步收到的Hash值。
  • 资源服务器返回一个网页,其中包含的代码可以获取Hash值中的令牌。
  • 浏览器执行上一步获得的脚本,提取出令牌。
  • 浏览器将令牌发给客户端。

3、用户名密码模式

密码模式(Resource Owner Password Credentials Grant)中,用户向客户端提供自己的用户名和密码。客户端使用这些信息,向”服务商提供商”索要授权。在这种模式中,用户必须把自己的密码给客户端,但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下。一般不支持refresh token。

步骤:

  • 用户向客户端提供用户名和密码。
  • 客户端将用户名和密码发给认证服务器,向后者请求令牌。
  • 认证服务器确认无误后,向客户端提供访问令牌。

4、客户端模式

指客户端以自己的名义,而不是以用户的名义,向”服务提供商”进行认证。严格地说,客户端模式并不属于OAuth框架所要解决的问题。在这种模式中,用户直接向客户端注册,客户端以自己的名义要求”服务提供商”提供服务,其实不存在授权问题。

步骤:

  • 客户端向认证服务器进行身份认证,并要求一个访问令牌。
  • 认证服务器确认无误后,向客户端提供访问令牌。

三、OAuth2协议安全相关

  1. 如何有效防范CSRF攻击:支持授权码许可类型的客户端应生成一个难以猜测state参数,并在首次向授权服务器发送请求时将其一同传递,OAuth规范要求授权服务器将此参数原样返回至重定向客户端URI,客户端要检查state参数的值,如果不一致则客户端需要中止授权流程。
  2. 令牌端点无需重定向为什么还需要携带redirect_uri:根据OAuth规范,如果在授权请求中指定了重定向URI,那么令牌端点也必须包含该重定向URI,这可防止攻击者使用被篡改的重定向URI获取受害者的授权码,让并无恶意的客户端将受害用户的资源访问权限关联到攻击者账户。
  3. 通过Referrer盗用授权码:基于HTTP Referrer造成的信息泄露,攻击者的最终目的是劫持资源拥有者的授权码。被攻击客户端的需要满足的前提要求:授权码模式+允许子目录的redirect_uri校验策略。
  4. 客户端不能多次使用同一个授权码:如果一个客户端使用了已经被用过的授权码,授权服务器必须拒绝该请求,并且应该尽可能地撤回之前通过该授权码颁发的所有令牌。
  5. 保证授权码只会颁发给经过身份认证的客户端:如果客户端不是保密客户端,则要确保授权码只会颁发给请求中client_id对应的客户端。如果不做这项检测,则任何一个客户端都可以使用颁发给别的客户端的授权码去获取访问令牌,这将产生不良后果。
  6. 精确匹配是少数始终安全的重定向URI核验算法。
  7. 授权服务器需要验证最初授权传入的redirect_uri与令牌请求传入的redirect_uri一致。
  8. 调用撤回令牌请求时如果授权服务器未找到令牌或者不允许出示令牌的客户端撤回该令牌,授权服务器还是会返回操作成功。为什么不返回失败呢?这是因为,如果这样做了,可能会无意中向客户端透露本不属于它的令牌。

延伸阅读1:OAuth2重要组件

  • OAuth客户端:是代表资源拥有者访问受保护资源的软件;
  • 受保护资源:能通过HTTP服务器进行访问,在访问时需要OAuth访问令牌。受保护资源需要验证收到的令牌,受保护资源对是否认可令牌拥有最终决定权;
  • 资源拥有者:有权将访问权限授权给客户端的主体。在大多数情况下,资源拥有者是一个人;
  • OAuth认证服务器:是一个HTTP服务,它在OAuth系统中充当中央组件,授权服务器对资源拥有者和客户端进行身份认证,让资源拥有者向客户端授权、为客户端颁发令牌、为受保护的资源校验令牌。
相关文章