OAuth2.0协议
Eddie一、OAuth2.0 是什么
OAuth2.0 是目前业界标准的第三方授权协议，专门用于跨系统、跨企业授权登录。
核心作用：让第三方应用在不获取用户账号密码的前提下，访问用户在平台的资源、完成登录授权。
重点区分 🔴：
-
JWT：是令牌格式，用于自家系统登录鉴权、轻量SSO
-
OAuth2.0：是授权协议标准，专门解决第三方跨系统授权问题
二、OAuth2.0 四大核心角色 🔴
所有授权模式，全部围绕这四个角色流转
-
资源所有者（用户）：拥有账号和数据的最终用户
-
客户端（第三方应用）：想要登录、获取用户信息的外部系统（比如掘金、网站小程序）
-
授权服务器：统一认证授权中心（微信、钉钉、企业认证中心），负责下发授权码、令牌
-
资源服务器：存放用户数据、业务资源的服务，校验令牌、返回用户资源
三、OAuth2.0 四种授权模式 🔴
四种模式覆盖所有业务场景，区分核心：信任度不同、客户端类型不同
1. 授权码模式（Authorization Code）🔥 行业标准、最安全、最常用
适用场景：外网第三方登录、所有公开的跨系统授权（微信登录、钉钉登录、Github登录）
核心特点：流程最长、安全性最高、支持刷新令牌、不会暴露密钥和令牌
完整流程：
-
用户访问第三方网站，选择微信登录
-
页面跳转至微信授权服务器，用户确认授权
-
授权服务器回调第三方地址，返回授权码（一次性、短期）
-
第三方服务携带授权码 + 客户端ID + 密钥，请求授权服务器
-
校验通过，下发 AccessToken + RefreshToken
-
第三方携带AccessToken请求资源服务器，获取用户信息，完成登录
核心优势：前端只接触授权码，令牌、密钥只在后端交互，完全不会泄露
2. 密码模式（Resource Owner Password）🟡
适用场景：自家内部互信系统、公司内部多子系统、自研APP登录
核心特点：信任度极高，流程极简，安全性低，绝对禁止对外网第三方使用
流程：用户直接输入账号密码，客户端携带账号密码请求授权服务器，校验通过直接返回令牌。
3. 客户端模式（Client Credentials）🟡
适用场景：无用户参与的服务间调用、后台定时任务、系统接口对接、中台鉴权
核心特点：不需要用户登录，没有用户概念，只代表应用本身授权
流程：客户端携带自身ID和密钥，直接向授权服务器申请令牌，用于服务之间接口调用鉴权。
4. 隐式简化模式（Implicit）🟢 基本淘汰
适用场景：老旧纯前端SPA项目、无后端服务的网页
核心缺点：跳过授权码步骤，直接在浏览器URL返回AccessToken，令牌暴露在地址栏，极易窃取、安全性极差
现状：目前企业基本全部淘汰，不再使用
四、OAuth2.0 核心优缺点
优点
-
标准化协议，通用性极强，所有平台统一适配
-
权限隔离，第三方应用无法获取用户账号密码
-
权限可控，用户可自主撤销授权
-
安全性高，支持令牌过期、刷新、失效回收
缺点
-
流程复杂、架构较重，部署成本高
-
单纯的自家系统登录，使用属于过度设计
五、行业真实选型规则 🔴
-
自家对外C端、前后端分离项目：不用OAuth，采用 JWT + 双Token（AccessToken+RefreshToken）（对应你合肥的项目经验）
-
自家内部同根域多子系统：不用OAuth，采用 JWT + 根域Cookie 实现轻量SSO
-
第三方登录、跨企业授权、外网对接：必须使用 OAuth2.0 授权码模式
-
企业内部互信系统对接：使用 密码模式
-
服务间调用、无用户场景：使用 客户端模式
六、总结 🔴
OAuth2.0是标准的跨系统授权协议，定义了四大核心角色，包含四种授权模式。其中授权码模式安全性最高，是外网第三方登录的标准方案；密码模式适用于企业内部互信系统；客户端模式用于无用户的服务间调用；隐式模式安全性差，目前基本淘汰。相比于JWT自研登录方案，OAuth2.0架构更标准但较重，所以普通自研项目一般只用JWT双Token登录，只有需要第三方跨企业授权的场景，才会使用OAuth2.0协议。