oAuth
介绍:
Open Authorization 是现代 web 鉴权体系的核心之一，它是一种鉴权体系而不是认证体系，目的是让一个应用在不拿到用户账户密码的情况下，访问用户在另一个平台上的受保护资源。
比如在登录某网站时选择“用微信登录”：
- 网站想获取你的微信昵称、头像；
- 微信（资源提供方）不会把你的密码给网站；
- 微信让你授权：“是否允许该网站访问你的公开信息？”；
- 你点“允许”，微信给网站一个临时的 令牌（token）；
- 网站就能用这个 token 去访问你的部分信息。
这整个过程就是 OAuth 在工作。
四个角色
资源所有者（Resource Owner）：用户，拥有资源所有权。
应用程序（Client）：准备访问用户资源的第三方应用。
授权服务器（Authorization Server）：专门负责授权的，比如微信的授权服务器，用于验证身份并发放令牌。
资源服务器（Resource Server）：存储受保护资源的，只接受携带有效令牌的资源访问。
授权流程：
以当前 OAuth 2.0 中应用最广泛的授权码模式为例：
- 用户访问第三方网站，选择用 github 账号登录；
- 网站跳转到 GitHub 登录页面，GitHub 询问用户是否同意授权；
- 用户点击“同意”，GitHub 重定向回网站，并附带一个 授权码
code； - 网站后端拿着
code去 GitHub 授权服务器换取 access_token； - 后端用这个 token 去访问 GitHub API 获取用户信息；
- 网站拿到数据后创建本地账号、登录完成。
🔑 核心在于：
- 网站永远拿不到用户密码；
- 用户可以随时在 GitHub 里撤销授权。
oAuth 和 JWT 有啥关系❓
角色：
- OAuth 负责“授权”，规范授权流程和规则
- JWT 负责“携带和验证身份信息”，是令牌内容的具体形态和验证方式。
背景：
- 传统的 session 模式，服务端要维护一个数据库存储用户登录会话信息，每次请求都要查库查表成本高
- JWT 是面向分布式的，因为他自己就包含了当前会话的权限、过期时间、用户ID等信息，只要服务端有密钥就能进行验证，具备 无状态验证、跨服务可用、携带基本信息和防篡改的特点。
所以现代基本这种微服务、分布式架构下，大部分都用JWT去做。
oAuth 和 单点登录 有啥关系❓
OAuth（开放授权）和单点登录（SSO, Single Sign-On）确实关系密切但不等价。
一、OAuth 是一种授权协议
OAuth（Open Authorization） 是一种标准协议，用于：
“让第三方应用在不获取用户密码的情况下，访问用户在另一服务上的资源”。
核心：
OAuth 解决的是 “资源访问授权” 问题。
用户仍然在 Google 登录；Google 授权后返回一个访问令牌（Access Token）给知乎。
知乎使用这个令牌访问 Google 的用户信息接口（通常是
/userinfo）。
二、单点登录（SSO）是一种登录机制
单点登录（Single Sign-On） 是一种机制，让用户“只需登录一次，就能访问多个相互信任的系统”。
比如你登录了公司内部的门户系统，就可以自动访问邮箱系统、OA 系统、考勤系统，不需要重复登录。
核心：
SSO 解决的是 “跨系统身份共享” 问题。
SSO 不规定用什么协议实现，但常见的实现协议包括：
SAML 2.0
CAS
OAuth 2.0 / OpenID Connect（OIDC）
三、两者的关系：OAuth 是 SSO 的基础之一
| 对比维度 | OAuth | 单点登录（SSO） |
|---|---|---|
| 定义 | 授权协议，让第三方访问资源 | 机制，让用户一次登录多处使用 |
| 目标 | 安全地授权资源访问 | 统一身份认证 |
| 涉及角色 | 资源所有者、资源服务器、客户端、授权服务器 | 用户、身份提供商（IdP）、服务提供商（SP） |
| 是否包含登录 | ✅ 可能包含（例如结合 OIDC） | ✅ 登录是核心 |
| 是否等价 | ❌ 不是 | ❌ 不是 |
🔹 OpenID Connect（OIDC） 就是在 OAuth 2.0 之上扩展身份层，
它才是真正常用于 SSO 的协议。OIDC = OAuth 2.0 + 身份认证🔹 OAuth 提供授权机制，OpenID Connect（基于 OAuth）提供认证机制，SSO 则利用这些协议实现“登录一次，处处可用”。