『Spring Security』你知道什么是OAuth2.0吗？

文章目录

• 第一部分 概念说明

  • 第二部分 简要介绍
  • （1） 授权概念
    • （2） OAuth2.0相关概念
    • （3） OAuth2.0授权的四种方式

• 三、授权码方式

  • （一）、OAuth2.0授权流程
    • 1、A网站通过引导用户访问B网站
      • 2、B网站要求用户登录并确认A网站的需求（即"A网站要求获得 xx 权限"），若获准则将重定向回A网站（或重定向URI）并返回一个授权码
      • 3、A网站通过获取该授权码来请求B网站的访问令牌
      • 4、B站点核实该授权码的有效性后将返回相应的访问令牌（Access Token）
      • 5、A站点利用获取到的访问令牌向B站点发起数据请求
      • 6、经核实后,B站点返回相应用户的详细信息

一、概念说明

OAuth作为Open Authorization的标准缩写而存在。

OAuth提供了针对用户资源的安全、开放且便捷的标准方案。

传统的授权机制与之相比的主要区别在于OAuth在授权过程中保护了用户的个人隐私信息——即使第三方无需访问用户的用户名和密码也能获取其权限。

OAuth2.0作为对前一个版本的延续，在设计上并不兼容（并非彻底取代）OAuth1.0。

二、简要介绍

（一）、授权概念

欲登录A平台 ， A平台要求用户提供关联方的数据 ，验证用户的身份信息 ，这就广泛采用的第三-party认证机制 。其中获取关联方的身份信息 ，就需采用OAuth认证机制 。例如以为例

OAuth授权确保第三方应用无法访问用户的详细信息（例如用户名和密码）。因此，在这种情况下，第三方应用无需使用用户的用户名和密码即可获取相应资源的授权。从而使得整个过程更加安全可靠。这意味着数据的所有者只需向B网站授予访问权限，并允许其收集相关用户数据。A网站则通过从B网站获取的一个临时访问令牌（token）来代替传统密码机制。

在功能上，令牌（Token）与密码具有相似性；它们均可以通过特定的方式实现系统接入。然而，在具体实现上存在一些区别：

• 时间限制 （Token存在时间限制，在到期后会自动失效（一般情况下会在到期前重新更新一次），这对于系统管理员来说是一个重要考虑因素；而Password通常不会受到此类自动刷新机制的影响）
• 权限范围 （在该系统中，“Tokens”仅具备读取功能，“Passwords”则提供了全面的权限控制）
• 用户可控 （系统设计赋予了用户对Tokens的有效期进行管理的能力，“Passwords”的设置通常不具备这种可管理性）

令牌和密码一样必须保密，泄露了令牌一般就等同于泄露了密码。

（二）、OAuth2.0相关概念

遵循标准[RFC 6749](https://tools.ietf.org/html/rfc6749)文件。文档中明确了OAuth指出了四种角色：

• 拥有权者 （赋予使用权限以访问受保护内容的实体通常是特定用户）
• 存储平台 （托管受保护的内容（通常包括用户数据），常与认证平台相关联）
• 访问终端 （提交请求获取服务的应用程序即第三-party应用程序）
• 认证平台 （发放凭证以允许第三方应用接入并登录的服务）

图片来自网络

基本上就是说资源所有者——也就是用户——同意后, 授权服务器依附于客户端发放相应的访问权限. 客户端凭借所获得的访问权限, 可以访问所需的数据.

授权流程的细节，详见后文。

（三）、OAuth2.0授权的四种方式

授权码方式（最常用的方式，安全性也最高，适用于那些有后端的 Web 应用 ）

优点：授权码在前端传递, 令牌存放于后端; 此外, 在资源服务器之间的通信都发生在后端. 这种前后端严格分隔的方式可有效防止敏感信息泄露.

隐藏式/简化式（即直接发放令牌，在无需上述颁发授权码的情况下完成这一流程。主要应用于纯前端场景 ）

缺点：该机制 getToken 经过前端未经加密传输的方式存在明显安全隐患。因此该方案仅适用于对敏感信息高度保密的需求相对较低的应用场景。而且该方案仅支持会话级（session-based）的有效期在会话期间有效一旦浏览器关闭getToken就会失效。

密码式（请求密码，并颁发令牌。适用于高度信任的应用 ）

缺点：这种方式必须由用户输入自己的用户名/密码，并且存在较高的安全隐患。因此这种方案仅限于那些无法通过其他授权方式的情况。而且这种方案仅适用于那些用户高度信任的应用场景。

客户端凭证（适用于没有前端的命令行应用)

缺点：该方案生成的标识符专门用于第三方服务系统，并不直接对应到个人用户。这意味着多个不同用户可能共享同一个标识符。

采用何种授权方案，在申请getToken之前

三、授权码方式

（一）、OAuth2.0授权流程

文中所指的A、B两个平台与上文设定一致：为了利用B平台的数据以实现访问A平台的需求，在必要时需以资源授权的方式从A平台获取支持。

为了便于查阅，在图中展示的每一步骤均被设置为标题形式，并且在图形化表示中清晰标注了各步之间的对应关系。

1、A网站让用户跳转到B网站

A网站客户端 申请授权的URI，包含以下参数：

基于高层概念的一种抽象方式定义统一资源标识符；而作为标识符的具体形式，则由URL这一特定方式来实现。

响应类型是一个必填字段, 表示授权类型的设置, 其中该字段的值固定为'code'.
客户端ID是一个必填字段, 用于标识参与 OAuth 请求的客户端设备.
重定向URI是一个可选字段, 主要用于指示授权响应中的重定向路径.
权限范围是一个可选字段, 定义了客户端请求的所有权限.
状态: 表示客户端当前的状态信息, 认证服务器将完整返回该信息给授权请求方.

B网站要求用户进行登录操作，并询问是否同意A网站需要获取 xx 权限。如果用户同意，则B网站将直接跳转回A网站（或指定重定向URI），并返回一个授权验证码。

通常必须获得用户的授权才能返回相应的凭证。

当然还可以将授权方式设为自动（虽然不够安全）。

B网站服务器 回应A网站客户端 的URI，包含以下参数：

* code（必选项）：表示授权码

该密码的有效期仅限于10分钟内。
客户端仅能单次使用该密码 ，否则会被授权服务器拒绝。

其中 ，每个密码都与唯一的客户端ID（client_id）及指定的重定向URI（redirect_uri）一一对应的关联性 。
其中
客户端ID（client_id）及指定的重定向URI（redirect_uri）
各自独立且唯一地关联到特定的密码实例。

state：当客户端发起的请求携带该参数时，认证服务器必须完全一致地将该参数纳入其响应。

3、A网站使用授权码，向B网站请求令牌

A端网站客户端向B端网站的授权服务器发起基于HTTPS协议下的POST类型网络请求，并包含以下必要字段：

• grant_type字段：记录着采用的授权模式，请确保其值设置为"'authorization_code'"。
• code字段：记录着上一步骤获取到的有效授权码。
• redirect_uri字段：配置其值需与A步骤中相应参数保持一致。
• client_id字段：指定客户端标识符。

4、B网站验证授权码，如果通过，则返回令牌（Access Token）

B网站授权服务器发送的HTTPS响应中包含了一段JSON数据,该数据包含以下几个必要参数:访问令牌和令牌类型,其中后者大小写不敏感且分为bearer型或mac型两种(具体区别可通过网络查阅了解);此外还包括可选参数:有效期,其单位为秒;若此字段未指定则需通过其他方式设定其有效期;以及更新密钥用于获取下一阶段的访问令牌;最后还有权限范围或作用域字段,此字段仅需填写当与客户端申请的权限范围一致时方可省略

5、A网站使用令牌，向B网站请求用户数据

A网站客户端

6、B网站验证令牌，如果通过，则返回用户数据

当认证凭证（Access Token）是有效的时，在此情况下B网站资源服务器将会返回资源信息，并使整个OAuth流程终止。

全文完，请大家多多支持！！！

如有错误，希望你能指出来，互相交流

装载请指明出处