OAuth2.0简介介绍（第三方授权登陆）

?🎉🎉欢迎来到我的CSDN主页！🎉🎉

🏅我是君易--鑨，一个在CSDN分享笔记的博主。📚📚

🌟推荐给大家我的博客专栏《SpringBoot开发之OAuth2.0系列》。🎯🎯

🎁如果感觉还不错的话请给我关注加三连吧！🎁🎁

---

前言

? ? ? ?前面几期的博客分享中都是分享都是有关联Security的知识分享，首先是Security的基础入门使用，在SpringBoot中集成Security使用；然后是Security的进阶使用，实现登陆功能、密码加密、记住我功能以及csrf防御；最后是Security连接数据库实现登陆功能以及权限分配。今天给大家带来的是OAuth2.0（第三方授权登陆）

一、OAuth2.0的简介

1. 概述

????????OAuth 2.0（Open Authorization 2.0）是一个授权框架，用于为第三方应用程序提供有限访问资源的方式，而无需将用户的凭证（如用户名和密码）传递给第三方。OAuth 2.0允许用户通过授权服务器授权第三方访问其受保护的资源，而不需要共享他们的凭证。

2.??OAuth 2.0 涉及以下角色：

• Third-party application：第三方应用程序，又称"客户端"（client），即例子中的"Gitee"。

• HTTP service：HTTP服务提供商，简称"服务提供商"，即例子中的微信。

• Resource Owner：资源所有者，又称"用户"，也就是你（user）。

• User Agent：用户代理，比如浏览器。

• Authorization server：授权服务器，即服务提供商专门用来处理认证授权的服务器。

• Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与授权服务器，可以是同一台服务器，也可以是不同的服务器。

OAuth的作用就是让"客户端"安全可控地获取"用户"的授权，与"服务提供商"进行交互。

3. 使用OAuth 2.0的优点和用途

OAuth 2.0的用途及优点

用途及优点	说明
用户数据安全性	用户不需要直接将其凭证（用户名和密码）提供给第三方应用程序，减少了凭证被泄露的风险。
限制权限范围	OAuth 2.0 允许资源所有者控制第三方应用程序访问其资源的范围，例如只授予读取权限而不是写入权限。
单点登录（Single Sign-On，SSO）	用户可以使用一组凭证登录多个相关联的服务，而不必每次都输入凭证。
开放性和通用性	OAuth 2.0 是一个开放的标准，被广泛应用于各种平台和应用程序类型，因此具有通用性和兼容性。
用户体验改善	用户可以更方便地授权第三方应用程序访问其数据，而无需频繁输入凭证信息。
授权管理和撤销权限	资源所有者可以随时撤销对第三方应用程序的访问权限，提高了授权管理的灵活性和安全性。

????????总的来说，OAuth 2.0 提供了一种安全、标准化和灵活的授权机制，使得用户可以更安全地授权第三方应用程序访问其资源，同时提高了用户体验并减少了安全风险。

二、OAuth2.0协议流程

1.?OAuth2.0的应用场景

• 原生app授权：app登录请求后台接口，为了安全认证，所有请求都带token信息，如果登录验证、 请求后台数据。

• 前后端分离单页面应用：前后端分离框架，前端请求后台数据，需要进行oauth2安全认证

• 第三方应用授权登录，比如QQ，微博，微信的授权登录。(本系列课程应

应用场景图解示例

?步骤详解

第1步：浏览器打开Gitee码云，点击微信方式授权登录，重定向到微信授权服务页面等待获取授权码；

第2步：用户打开手机登录微信扫描“二维码”，点击“允许”授权，将重定向到客户端（Gitee）应用提供的URI；

第3步：客户端（Gitee）使用上一步获取的授权码，向微信授权服务器申请令牌（Token）；

第4步：微信授权服务器对客户端（Gitee）进行认证以后，确认无误，同意发放令牌；

第5步：客户端使用令牌向资源服务器（微信）申请获取资源；

第6步：资源服务器（微信）确认令牌无误后，同意向客户端开放资源

2. 认证流程

?认证流程图解

图解说明

1. 客户端注册

????????客户端在授权服务器上进行注册，获得客户端标识和客户端密钥。这是为了在后续的流程中进行身份验证。

2.?请求授权

?客户端向资源所有者请求授权，通常通过重定向用户到授权服务器的认证端点。

（请求路径可能如下）

GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=SCOPE&state=STATE

参数说明

• response_type=code：指定授权码授权流程。
• client_id：客户端标识，用于识别客户端。
• redirect_uri：授权后重定向的URI，用于接收授权码。
• scope：指定请求的权限范围。
• state：客户端生成的随机值，用于防止跨站请求伪造（CSRF）攻击。

3.?用户授权

????????资源所有者登录授权服务器，同意或拒绝授权请求。如果同意，授权服务器将用户重定向回客户端，并附带授权码。

?4.?获取授权码

授权服务器将授权码返回给客户端，附带在重定向的URI中。

GET /redirect_uri?code=AUTHORIZATION_CODE&state=STATE

参数说明

• code：授权码。
• state：客户端传递的原始状态值。

?5.?交换访问令牌

客户端使用授权码向授权服务器请求访问令牌。（携带参数如下）

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

?参数说明

• grant_type=authorization_code：指定使用授权码交换访问令牌。
• code：授权码。
• redirect_uri：必须与授权请求中使用的一致。
• client_id：客户端标识。
• client_secret：客户端密钥，用于身份验证。

?6.?获取访问令牌

授权服务器验证授权码，并颁发访问令牌和可能的刷新令牌。（返回参数）

{
  "access_token": "ACCESS_TOKEN",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "REFRESH_TOKEN",
  "scope": "SCOPE"
}

参数说明

• access_token：访问令牌，用于访问受保护资源。
• token_type：表示令牌类型，通常为Bearer。
• expires_in：访问令牌的有效期（秒）。
• refresh_token：用于获取新访问令牌的刷新令牌。
• scope：实际授予的权限范围

?7.?访问受保护资源

客户端使用访问令牌向资源服务器请求受保护资源。

GET /resource
Authorization: Bearer ACCESS_TOKEN

?参数说明

• Authorization：包含Bearer令牌的HTTP头。

三、OAuth2.0授权模式

1. 授权码模式

????????这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

适用场景：目前主流的第三方验证都是采用这种模式

?图解

2.??简化(隐式)模式

????????也称为隐式授权流程（Implicit Flow），是OAuth 2.0授权框架的一种流程，用于在移动应用和 Web 前端应用等场景中获取访问令牌。相较于授权码授权流程，简化模式省略了获取授权码的步骤，直接在授权请求中获得访问令牌。

?主要流程

? ? ? ? 1.构建授权请求： 客户端应用向授权服务器发送授权请求。请求通常是一个HTTP GET请求，包含必要的参数

• response_type=token：指示使用简化模式。
• client_id：标识客户端的唯一ID。
• redirect_uri：授权成功后重定向的URI。
• scope：请求访问资源的权限范围。
• state：用于防止CSRF攻击的随机字符串。

?????????2.用户授权： 用户在授权服务器登录并授权客户端应用。授权服务器验证用户身份并确认授权请求。如果用户同意授权，授权服务器将在重定向URI的片段中返回访问令牌。

GET /redirect_uri#access_token=ACCESS_TOKEN&token_type=Bearer&expires_in=3600&scope=SCOPE&state=STATE

• access_token：访问令牌，用于向资源服务器请求受保护资源。
• token_type：通常为Bearer。
• expires_in：访问令牌的有效期。
• scope：实际授予的权限范围。
• state：原始的客户端状态信息。

? ? ? ? 3.?访问受保护资源： 客户端应用获得访问令牌后，可使用该令牌向资源服务器请求受保护资源。请求中会在HTTP头中包含访问令牌信息，以验证并获取所需的资源。

GET /protected_resource
Authorization: Bearer ACCESS_TOKEN

• Authorization：包含Bearer令牌的HTTP头，用于验证客户端的访问权限。

? ? ? ? ?4.处理访问令牌： 客户端应用收到访问令牌后，可用于在访问资源时进行身份验证和授权，访问受保护的API端点或资源。

3. 密码模式

?????????是OAuth 2.0授权框架中的一种授权流程。它允许客户端应用程序直接使用用户的用户名和密码来获取访问令牌，而无需经过授权服务器的授权过程。这种模式通常用于用户信任客户端应用程序并且客户端能够安全地存储用户凭据的情况。

主要流程?

????????1.构建授权请求： 客户端应用程序直接向授权服务器发送包含以下参数的HTTP POST请求：

grant_type=password：指示使用密码模式。
username：用户的用户名。
password：用户的密码。
client_id：标识客户端的唯一ID。
client_secret：客户端的秘密信息，用于身份验证。

????????2.获取访问令牌： 授权服务器验证用户提供的用户名和密码。如果验证成功，授权服务器将颁发访问令牌和可能的刷新令牌。

POST /token_endpoint
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=USER&password=PASSWORD&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

• access_token：用于访问受保护资源的访问令牌。
• token_type：通常为Bearer。
• expires_in：访问令牌的有效期。
• refresh_token：可用于获取新访问令牌的刷新令牌。

????????3.使用访问令牌： 客户端应用程序使用获得的访问令牌向资源服务器请求受保护资源。

GET /protected_resource
Authorization: Bearer ACCESS_TOKEN

• Authorization：包含Bearer令牌的HTTP头，用于验证客户端的访问权限。

4.??客户端模式

????????客户端模式（Client Credentials Grant）是OAuth 2.0授权框架中的一种授权流程。这种模式主要用于机器对机器的通信场景，而不是用户与应用程序之间的通信。在这种模式下，客户端（通常是一个服务或应用程序）直接与授权服务器交互以获取访问令牌，而无需代表用户。

?????????主要流程和上述的密码模式相差不差

5. 四种模式的区别

主要区别和选择依据：

• 安全性：?授权码模式和密码模式较为安全，因为它们要求用户直接与认证服务器交互。而隐式授权模式适用于纯前端应用，相对较不安全。
• 应用场景：?不同的应用场景可能需要不同的授权模式。例如，Web应用一般使用授权码模式，移动应用可以选择密码模式，前端应用可以选择隐式授权模式，机器对机器通信使用客户端模式。
• 实现难度：?隐式授权模式相对简单，因为它省略了获取授权码的步骤，但相应地牺牲了一些安全性

---

🎉🎉本期的博客分享到此结束🎉🎉

📚📚各位老铁慢慢消化📚📚

🎯🎯下期博客博主会带来新货🎯🎯

🎁三连加关注，阅读不迷路?！🎁