概述

OAuth是一个关于授权( authorization )的开放网焰标准协议,简单理解就是一种授权机制,它是在客户端和资源所有者之间的授权层,用来分离两种不同的角色。在资源所有者同意并向客户端颁发令牌后,客户端携带令牌可以访问资源所有者的资源。OAuh2.0是OAuth协议的一个版本,2.0版本不兼容1.0版本,相当于1.0版本已经废弃。

OAuth就是一种授权机制.数据的所有者告诉系统,同意授权第三方应用进入系统,获取这些数据。系统从而产生一个短期的进入今牌( token ),用来代替密码,供第三方应用使用。

OAuth 2.0 定义了四种不同的授权模式,用来获取访问令牌(Access Token)。这些模式适用于不同的使用场景,具体包括:授权码模式(Authorization Code)、隐藏式(Implicit)、密码凭证模式(Resource Owner Password Credentials)客户端凭证模式(Client Credentials)

一、授权码模式(Authorization Code Grant)

授权码模式 是最常用、最安全的一种授权方式,通常用于服务器端应用(Server-side Apps),它借助授权码来进行授权,避免直接暴露用户凭证。此模式分为两个步骤:首先客户端获取授权码(Authorization Code),然后使用授权码去获取访问令牌(Access Token)。

授权流程:

  1. 用户访问客户端:用户尝试访问第三方应用(如 Web 或移动应用)。
  2. 客户端重定向至授权服务器:客户端将用户重定向到 OAuth 授权服务器,并携带必要的参数(如 client_id、redirect_uri、response_type=code、scope=read 等)。
    • response_type=code 表示本次请求需要返回授权码
    • client_id 让第三方知道是谁在请求数据
    • redirect_uri 第三方处理完连接请求后的跳转地址
    • scope=read 表示授权的范围,read 表示对授权资源进行只读的操作
  3. 用户登录并授权:用户在授权服务器上登录,并同意客户端访问其资源。
  4. 授权服务器返回授权码:如果用户授权成功,授权服务器会将授权码通过重定向(通常到 redirect_uri)返回给客户端。
  5. 客户端请求访问令牌:客户端将授权码、client_id、client_secret 发送到授权服务器的令牌端点(Token Endpoint),以交换访问令牌。
  6. 授权服务器返回访问令牌:授权服务器验证授权码的有效性后,返回访问令牌(Access Token)。

示例流程图:

客户端 --------> 授权服务器 --------> 用户授权
               <--------  授权码  <--------
客户端 ------> 授权服务器(带授权码)
              <-------- 访问令牌  <--------

适用场景:

  • 服务器端应用或 web 应用程序。
  • 客户端可以安全存储 client_secret。
  • 高安全性要求的场景。

二、隐藏式(Implicit Grant)

隐藏式授权 是专门为浏览器端应用(如单页应用,SPA)设计的授权模式。与授权码模式不同的是,隐藏式授权模式直接将访问令牌返回给客户端,而不是通过授权码交换令牌。它减少了一次与授权服务器的交互,使得流程更简化,但安全性较低,因为令牌直接暴露给用户代理(浏览器)。

授权流程:

  1. 用户访问客户端:用户通过浏览器访问客户端应用。
  2. 客户端重定向到授权服务器:客户端重定向用户到 OAuth 授权服务器,并发送请求(包含 client_id、redirect_uri、response_type=token 等参数)。
  3. 用户登录并授权:用户在授权服务器上登录并授权客户端应用访问其资源。
  4. 授权服务器返回访问令牌:授权服务器直接将访问令牌通过 URL Fragment(#access_token=…)返回给客户端,客户端可以在重定向后的 URL 中获取令牌。

安全性考虑:

由于令牌直接在浏览器中暴露,因此存在安全风险。通常会通过缩短令牌有效期、使用 HTTPS、加密存储等方法来增强安全性。

示例流程图:

客户端 --------> 授权服务器 --------> 用户授权
               <--------  访问令牌 <--------

适用场景:

  • 单页应用程序(SPA)。
  • 客户端无法安全存储 client_secret。
  • 安全要求较低,或只需要短期访问令牌的场景。

相较于上述主要的区别就是少了一个授权码的过程。

三、密码凭证模式(Resource Owner Password Credentials Grant)

密码凭证模式 直接使用用户的用户名和密码进行授权。这种方式适用于客户端和资源所有者(用户)之间高度信任的场景,通常仅用于内部应用或用户直接向应用信任度非常高的情况。客户端直接使用用户的凭据向授权服务器请求访问令牌。

授权流程:

  1. 用户向客户端提供第三方的用户名和密码:用户输入自己的用户名和密码。
  2. 客户端请求访问令牌:客户端将用户名、密码、client_id、client_secret 发送到授权服务器的令牌端点。
  3. 授权服务器验证用户凭据:授权服务器验证用户名和密码的正确性。
  4. 授权服务器返回访问令牌:验证成功后,授权服务器返回访问令牌。

示例流程图:

客户端 ------> 授权服务器
              <-------- 访问令牌  <--------

安全性考虑:

密码凭证模式存在较高的安全风险,因为客户端必须收集和存储用户的用户名和密码。通常不推荐使用这种方式,除非客户端和用户之间有高度信任关系,并且在后台环境下运行。

适用场景:

  • 客户端与用户之间有高度信任(如自有移动应用、内部应用)。
  • 无法使用授权码模式的场景。
  • 用户直接与客户端交互,客户端能够安全地处理用户凭据。

四、客户端凭证模式(Client Credentials Grant)

客户端凭证模式 是 OAuth 2.0 中最简单的一种授权方式,适用于服务器到服务器(Server to Server)的授权场景。客户端以自己的身份而不是用户的身份向授权服务器请求访问资源。

授权流程:

  1. 客户端请求访问令牌:客户端使用其 client_id 和 client_secret 向授权服务器发送请求。
  2. 授权服务器验证凭据:授权服务器验证客户端的凭据(client_id 和 client_secret)。
  3. 授权服务器返回访问令牌:验证成功后,授权服务器返回访问令牌。

示例流程图:

客户端 ------> 授权服务器
              <-------- 访问令牌  <--------

安全性考虑:

  • 客户端凭证模式的安全性依赖于客户端和授权服务器之间的信任。由于没有涉及用户身份验证,因此适用于访问应用程序自己的资源,而非用户资源。

适用场景:

  • 服务器与服务器之间的通信,例如微服务之间的通信。
  • 无用户交互的自动化系统。
  • 客户端自己管理的资源,且无需用户授权的场景。

五、四种授权模式的比较

模式类型安全性使用场景特点适用客户端
授权码模式Web 应用,服务器端最常用,需服务器端处理服务器端应用
隐藏式模式较低单页应用(SPA)简化流程,令牌直接暴露客户端应用(浏览器)
密码凭证模式中等内部应用需要用户直接提供凭据内部应用或信任的客户端
客户端凭证模式服务到服务无需用户参与服务器应用(无用户)

总结

  • 授权码模式 是最常用、最安全的方式,适用于需要用户授权并且有服务器参与的应用。
  • 隐藏式模式 是为单页应用设计的,简化了流程,但安全性较低。
  • 密码凭证模式 允许用户直接向客户端提供凭据,适用于客户端和用户高度信任的场景。
  • 客户端凭证模式 则用于服务器与服务器之间的授权,无需用户参与。

点赞(0) 打赏

评论列表 共有 0 条评论

暂无评论

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部