5分钟理清：Session、JWT、Token、SSO、OAuth 2.0 认证逻辑

5分钟理清：Session、JWT、Token、SSO、OAuth 2.0 认证逻辑

 

 

 

 

原创

 

 

 

 

 

 

 

田东晟

 

 

 

 

 

 

 

 

 

 

 

 

IT过客

 

 

 

 

2025年09月26日 14:31

四川

 

 

4人

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

认证与授权是系统安全的核心，Session、JWT、Token、SSO、OAuth 2.0 是最常用的技术。一张图拆解它们的工作逻辑，帮你快速区分～

 

一、基础认证：WWW-Authenticate

 

浏览器直接向服务器发送用户名+密码，服务器验证后登录。

缺点：登录状态难管理（无法灵活控制登录生命周期），且每次请求都传密码，风险高。

 

二、Session-Cookie：服务端存状态

 

 1. 浏览器登录后，服务器生成 Session（存用户状态），并给浏览器返回 Session ID（存在 Cookie 里）。

 

 2. 后续请求时，浏览器带 Session ID，服务器通过 ID 找到对应 Session，确认身份。

特点：状态存在服务端，易管理，但分布式场景下（多服务器）需共享 Session（否则换服务器就需重新登录）。

 

三、Token：无状态认证

 

 1. 浏览器登录后，服务器生成 Token（含用户信息），返回给浏览器（存在 Cookie 或本地存储）。

 

 2. 后续请求时，浏览器带 Token，服务器调用「Token 验证服务」校验合法性。

特点：服务端无状态（不用存 Session），适合分布式系统；但 Token 验证需额外服务支持。

 

四、JWT（JSON Web Token）：自包含的 Token

 

Token 的“增强版”，结构分三部分：header（算法）、payload（用户信息）、signature（签名）。

 

 1. 服务器用密钥生成 JWT，返回给浏览器。

 

 2. 后续请求带 JWT，服务器用密钥验证签名，无需查数据库。

优势：自包含（ payload 存信息）、验证快，还支持跨站登录（不同域名间传递身份）。

 

五、SSO（单点登录）：一次登录，多系统通行

 

用户只需在 统一认证中心（如 sso.com）登录一次，就能访问多个关联系统（如 a.com、b.com）。

原理：各系统跳转到统一认证中心登录，成功后返回凭证，各系统验证凭证后免登录。

场景：企业内部多系统（OA、邮件、CRM），减少重复登录。

 

六、OAuth 2.0：第三方授权（不是“登录”，是“授权”）

 

让应用无需获取用户密码，就能获得第三方平台的权限（如让知乎获取你的 GitHub 仓库）。

核心流程：

 

 • 授权码模式（最常用）：应用跳转到第三方平台（如 GitHub），用户授权后，平台返回授权码，应用用授权码换访问令牌，最终用令牌调用第三方接口。

 

 • 还有客户端凭证模式（服务间授权）、密码模式（直接传密码，少用）等。

 

怎么选？看场景

 

 • 小系统、单服务器 → Session-Cookie；

 

 • 分布式系统、想减少服务端存储 → Token 或 JWT；

 

 • 企业多系统整合 → SSO；

 

 • 需第三方平台授权（如社交登录、调用第三方 API） → OAuth 2.0。

 

这些技术不是互斥的，甚至会结合使用（如 SSO 内部用 JWT 传递身份，OAuth 2.0 对接第三方）～