十大鉴权方案深度对比：从Session到SSO，前端与后端如何选择？

在构建现代Web应用或移动应用时，身份验证与授权是确保系统安全的核心环节。面对诸如Token、Cookie、Session、JWT、单点登录等多种方案，开发者该如何选择？哪一种最安全？哪一种最适合你的业务场景？

本文将系统性地梳理和对比前后端通信中常用的10种鉴权与授权方案，帮助你构建清晰的技术选型思路。

认证、授权、鉴权与权限控制

在深入具体方案前，必须厘清几个核心概念：认证 (Identification)、授权 (Authorization)、鉴权 (Authentication) 和权限控制 (Access Control)。它们是构成安全体系的上下游环节。

• 认证：确认声明者的身份，即“证明你是你”。例如使用身份证、用户名密码、手机验证码等。
• 授权：资源所有者赋予执行者特定范围的操作权限。例如物业管理处发放门禁卡、服务器颁发令牌(Token)。
• 鉴权：对声明者所声明的权限真实性进行鉴别确认的过程。例如门禁系统识别门禁卡、服务器校验Token的有效性。
• 权限控制：根据鉴权结果，执行“允许”或“禁止”操作。例如网关根据用户角色决定是否放行API请求。

这四者是一个依次发生、紧密关联的链条。

在某些场景中，这些环节可能几乎同时发生（如刷门禁卡），也可能分步进行（如网站登录后的一系列操作）。

1. HTTP 基本认证 (Basic Authentication)

这是一种简单的客户端身份验证方式，通过用户名和密码进行验证。

认证流程

1. 客户端请求受限资源。
2. 服务器返回 401 Unauthorized 状态码及 WWW-Authenticate 头部，要求进行Basic认证。
3. 客户端（通常是浏览器弹出对话框）将用户名和密码用冒号连接后，进行Base64编码，并通过 Authorization 头部发送给服务器。
4. 服务器解码并验证凭证，成功则返回资源，失败则返回 403 Forbidden。

请求示例：

GET /protected-resource HTTP/1.1
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

优点与缺点

• 优点：简单，所有主流浏览器均支持。
• 缺点：
  1. 极不安全：Base64编码等同于明文传输，易被拦截和解码。
  2. 无法主动注销：除非关闭浏览器或清除记录。
  3. 易遭受重放攻击。

使用场景

仅适用于内部网络或对安全性要求极低的场景。

2. Session-Cookie 认证

这是传统Web应用最常用的方案，利用服务端的Session和浏览器的Cookie实现状态保持。

核心概念

• Cookie：由服务器发送到浏览器并保存在本地的一小块数据，会在下次请求同一服务器时被携带。它解决了HTTP无状态的问题，但存储在客户端，存在安全风险。
• Session：服务器为特定用户会话创建的数据存储结构，保存在服务器内存、数据库或缓存（如Redis）中。Session ID用于标识不同会话。

认证流程

1. 客户端提交用户名密码登录。
2. 服务器验证通过，创建Session并生成唯一Session ID。
3. 服务器通过响应头 Set-Cookie 将Session ID发送给客户端。
4. 客户端后续请求会自动携带此Cookie。
5. 服务器通过Cookie中的Session ID查找对应Session，完成鉴权。

优点与缺点

• 优点：
  1. Cookie使用简单。
  2. Session数据在服务端，相对安全，易于管理（登录/注销即增删Session）。
  3. 前端可无感操作。
• 缺点：
  1. 依赖Cookie：若浏览器禁用Cookie则功能失效。
  2. 有安全风险：Cookie易被截获或遭受CSRF攻击。
  3. 增加服务器开销：需要存储Session，用户量大时影响性能。
  4. 对移动端/原生APP支持不友好。

使用场景

适用于中大型网站（非移动端APP）。由于Session通常需要集中存储（如Redis），会带来额外的服务器成本。

3. Token 认证

为解决Session-Cookie的扩展性和移动端支持问题，Token认证方案应运而生。

什么是Token？

Token是访问资源接口时所需的凭证。通常由用户标识(uid)、时间戳(time)和签名(sign)组成。客户端登录后获得Token，后续请求携带此Token，服务器验证其有效性即可。

认证流程

1. 客户端使用凭证登录。
2. 服务器验证凭证，生成并返回Token。
3. 客户端保存Token（Web可存于localStorage或Cookie，APP存于本地）。
4. 客户端请求API时，在Authorization头部或其他方式携带Token。
5. 服务器验证Token，有效则返回数据。

优点与缺点

• 优点：
  1. 服务端无状态：Token自包含用户信息，利于分布式系统扩展和服务共享用户状态。
  2. 支持移动端。
  3. 安全性较好：避免CSRF攻击，Token可设置较短有效期。
  4. 支持跨域。
• 缺点：
  1. 需前后端配合。
  2. Token体积通常比Session ID大，增加带宽消耗。
  3. 加解密操作消耗性能。
  4. Token一旦签发，在有效期内无法主动废止。

Refresh Token 机制

为平衡安全与体验，引入双Token机制：

• Access Token：用于访问业务接口，有效期短。
• Refresh Token：用于获取新的Access Token，有效期长，存储于服务端或安全客户端。

当Access Token过期，客户端使用Refresh Token申请新Token，无需用户重新登录。

4. JWT (JSON Web Token)

JWT是Token的一种具体实现标准，通过签名后的JSON对象作为令牌。

JWT的组成

JWT形如 xxxxx.yyyyy.zzzzz，由三部分组成：

1. Header：声明类型和签名算法，如 {"alg": "HS256", "typ": "JWT"}，经Base64编码。
2. Payload：存放实际传递的数据（Claims），包括标准声明（如iss签发者、exp过期时间）和自定义声明。
3. Signature：对前两部分的签名，防止数据篡改。生成方式：HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)。

使用方式

JWT可存储于localStorage或Cookie，通常通过HTTP请求头传递：

Authorization: Bearer <your.jwt.token>

认证流程

流程与普通Token类似，但服务端无需查询数据库，直接验证JWT签名并从Payload中读取用户信息即可。

优点与缺点

• 优点：
  1. 自包含信息，减少数据库查询。
  2. 适用于无状态的RESTful API，易于扩展。
• 缺点：
  1. 一旦签发，在有效期内无法废弃。
  2. Payload默认不加密，敏感信息不应存放其中。
  3. Token长度较长。

5. 单点登录 (Single Sign On, SSO)

SSO允许用户登录一次后，访问所有相互信任的应用系统。

同域SSO

主域名相同（如 tieba.baidu.com 和 pan.baidu.com）时，实现简单。只需在认证中心设置Cookie的Domain为 .baidu.com，各子域即可共享登录状态。本质仍是Session-Cookie。

跨域SSO

主域名不同时，需要独立的认证中心，常用CAS (Central Authentication Service) 协议。

CAS 认证流程

以用户访问淘宝(taobao.com)和天猫(tmall.com)为例：

1. 用户访问未登录的淘宝，被重定向至CAS认证中心(sso.com)。
2. CAS发现无登录票据(TGC)，重定向至登录页。
3. 用户登录，CAS生成TGC（存于Cookie）和授权票据ST，携带ST重定向回淘宝。
4. 淘宝用ST向CAS验证，成功后建立本地会话。
5. 用户访问天猫时，被重定向至CAS。
6. CAS通过浏览器携带的TGC发现用户已登录，直接签发新的ST给天猫。
7. 天猫用ST向CAS验证，成功后建立本地会话。

核心票据：

• TGC (Ticket Granting Cookie)：CAS发给用户的登录凭证，存储在Cookie中。
• ST (Service Ticket)：CAS为用户访问某个具体服务签发的一次性票据。

6. OAuth 2.0

OAuth 2.0是一个开放授权标准，允许用户授权第三方应用访问其存储在服务提供商处的资源，而无需分享用户名和密码。常用于“使用微信/QQ/GitHub登录”。

四种授权模式

OAuth 2.0定义了四种模式以适应不同场景。

1. 授权码模式 (Authorization Code Grant)

最常用、最安全，适用于有后端的Web应用。

1. 第三方应用将用户重定向至授权服务器。
2. 用户登录并同意授权。
3. 授权服务器将授权码(code)通过重定向返回给第三方应用的后端回调地址。
4. 第三方应用后端使用code、client_id和client_secret向授权服务器交换访问令牌(access_token)。

2. 隐式授权模式 (Implicit Grant)

适用于纯前端SPA应用。授权服务器直接将access_token通过URL片段(#)返回给前端，省略授权码步骤。安全性较低。

3. 密码模式 (Resource Owner Password Credentials Grant)

用户直接将用户名密码交给第三方应用，该应用以此直接向授权服务器申请令牌。仅适用于高度信任的应用（如自家公司的不同产品线）。

4. 客户端模式 (Client Credentials Grant)

客户端以自己的名义（而非用户名义）向授权服务器认证，获取用于访问客户端自身资源的令牌。适用于机器对机器的认证。

模式选型

根据客户端类型和安全需求选择：

7. 联合登录与信任登录

• 联合登录：使用A网站的账号密码登录B网站，类似于OAuth 2.0的密码模式，需要高度信任。
• 信任登录：所有无需用户主动参与的登录，如设备绑定登录。通常指利用第三方成熟用户库（如QQ、支付宝）进行校验，OAuth 2.0是实现信任登录的典型手段。

8. 唯一登录

确保同一账号同一时间只能在一个设备或地点登录，后登录者会使先登录者“下线”。

实现思路

1. 用户首次登录，服务端生成Token并记录该Token与用户、设备的绑定关系。
2. 同一用户在其他设备登录时，服务端生成新Token，并使旧Token失效。
3. 原设备使用旧Token请求时，服务端校验发现Token无效，强制跳转至登录页。

9. 扫码登录

常见于PC端网站使用移动端APP（如微信）扫码登录。涉及PC端、移动端和服务端三端协作。

认证流程

1. 待扫码：PC端生成二维码（对应一个服务器生成的临时ID），并轮询其状态。
2. 已扫码待确认：用户用已登录的APP扫描二维码，APP将扫码动作和自身Token通知服务器，服务器将二维码ID与用户临时绑定，并通知PC端状态变更。
3. 已确认：用户在APP上点击“确认登录”，服务器正式建立二维码ID与用户的绑定，生成PC端Token，并通知PC端登录成功。

10. 一键登录（适用于原生APP）

利用运营商的数据网络，直接获取本机手机号完成认证，无需输入账号密码和验证码。

认证流程

1. SDK初始化：APP集成运营商或第三方SDK。
2. 唤起授权页：APP调用SDK，SDK通过蜂窝网络向运营商获取手机号掩码并展示给用户确认。
3. 同意授权：用户确认后，SDK获取到用于换号的Token。
4. 取号：APP将Token发送给自家服务器，服务器用Token向运营商服务端请求，获得完整手机号，完成登录/注册。

注意：需用户开启蜂窝网络，失败时需有短信验证码等备选方案。

总结与选型建议

方案	核心特点	适用场景
HTTP基本认证	简单，极不安全	内部网络或安全要求极低的场景
Session-Cookie	经典，服务端有状态，依赖Cookie	传统Web网站（非移动端）
Token/JWT	服务端无状态，支持跨域与移动端，需管理Token生命周期	前后端分离、移动应用、分布式架构
单点登录(SSO)	一次登录，多系统通行	拥有多个子系统的中大型企业
OAuth 2.0	安全的第三方授权标准	需要第三方登录（微信/QQ等）或开放API
扫码登录	移动端确认PC端登录	已具备移动端和PC端产品的场景
一键登录	免密，依赖运营商网络	对转化率要求高的原生APP

选择哪种方案，取决于你的应用类型（Web/APP）、架构（单体/微服务）、安全要求以及对用户体验的考量。理解网络与安全的基本原理是做出正确技术决策的基础。

---

本文旨在系统梳理常见鉴权方案，更多技术实践与深度讨论，欢迎访问 云栈社区。