认证和授权完全指南

概述

在现代网络安全体系中，认证（Authentication） 和 授权（Authorization） 是保障系统安全的两大核心机制：

  • 认证：验证用户身份（”你是谁？”）
  • 授权：确认访问权限（”你能做什么？”）

本文将从协议和Token两个维度，系统性阐述认证授权的技术体系。

一、认证授权协议体系

1. OAuth 2.0 - 授权标准协议

OAuth 2.0 是现代互联网授权的基石，专注于授权（资源访问权限的委派），而非直接处理用户身份认证。

核心角色

角色 说明 示例
资源所有者（Resource Owner） 拥有资源的用户 微信用户
客户端（Client） 请求访问资源的应用 第三方小程序
授权服务器（Authorization Server） 颁发Token的服务 微信授权服务器
资源服务器（Resource Server） 存储受保护资源的服务 微信用户信息API

四种授权模式

  1. 授权码模式（Authorization Code）

    • 适用场景：Web应用（服务端安全）
    • 安全性：最高，推荐使用
    • 流程：用户授权 → 获取授权码 → 后端交换Token

  2. 隐式模式（Implicit）

    • 适用场景：SPA或原生App（客户端不安全）
    • 注意：OAuth 2.1已废弃，建议使用PKCE

  3. 密码模式（Resource Owner Password Credentials）

    • 适用场景：高度信任的客户端
    • 风险：直接暴露用户密码

  4. 客户端凭证模式（Client Credentials）

    • 适用场景：服务端间通信（无用户参与）
    • 特点：机器对机器的授权

典型应用场景

  • 第三方登录（微信、QQ、GitHub登录）
  • API访问控制
  • 移动应用授权

img

2. OpenID Connect (OIDC) - 身份认证层

OpenID Connect 在OAuth 2.0基础上扩展，专门解决身份认证问题，是OAuth 2.0 + 身份认证的完整解决方案。

核心特性

  • ID Token：JWT格式，包含用户身份信息（如姓名、邮箱、用户ID）
  • UserInfo端点：通过Access Token获取用户详细信息
  • 标准化声明：定义了标准的用户属性字段

OIDC 流程

1
2
3
4
5
6
1. 用户访问客户端应用
2. 重定向到OIDC提供商进行认证
3. 用户授权后返回授权码
4. 客户端交换授权码获取Token
5. 返回Access Token + ID Token
6. 通过UserInfo端点获取用户信息

img

典型应用场景

  • 企业SSO：使用Google Workspace登录企业应用
  • 消费级SSO：使用Apple ID登录第三方应用
  • 跨域认证：多个子域名系统的统一登录

3. SAML 2.0 - 企业级身份联邦

SAML 2.0 是企业级认证与授权标准，基于XML实现跨域单点登录，在企业环境中广泛部署。

核心架构

1
2
3
Identity Provider (IdP) ←→ Service Provider (SP)
      ↓                           ↓
   用户认证                    资源访问

关键组件

  • 断言（Assertion）：XML格式的安全声明，包含用户身份和权限信息
  • 身份提供者（IdP）：认证用户并生成SAML断言（如企业AD）
  • 服务提供者（SP）：依赖IdP的断言提供服务访问（如SaaS应用）

SAML SSO 流程

  1. 用户访问SP应用
  2. SP重定向到企业IdP
  3. IdP验证用户身份
  4. 生成SAML断言并返回SP
  5. SP验证断言并授权访问

img

企业应用场景

  • Office 365集成：通过ADFS实现企业SSO
  • SaaS应用集成：Salesforce、ServiceNow等企业应用
  • 混合云环境：本地AD与云服务的身份联邦

4. Kerberos - 票据认证协议

Kerberos 是基于票据的网络认证协议，通过密钥分发中心（KDC）实现安全认证，有效防止中间人攻击。

核心组件

  • KDC（Key Distribution Center）：密钥分发中心
  • TGT（Ticket-Granting Ticket）：用户首次认证后的长期票据
  • 服务票据（Service Ticket）：访问具体服务的临时票据

Kerberos 认证流程

1
2
3
4
5
Client → AS (Authentication Server): AS_REQ
AS → Client: AS_REP (TGT)
Client → TGS (Ticket-Granting Server): TGS_REQ (TGT)
TGS → Client: TGS_REP (Service Ticket)
Client → Service: AP_REQ (Service Ticket)

img

5. LDAP - 目录服务协议

LDAP（Lightweight Directory Access Protocol） 是访问和维护目录服务的标准协议，主要用于用户和组织信息的查询与管理。

核心功能

  • 目录查询：用户、组织架构、权限信息查询
  • 身份验证：用户名密码验证
  • 属性管理：用户属性的增删改查

常见实现

  • Microsoft Active Directory (AD)：Windows域环境的标准
  • OpenLDAP：开源LDAP实现
  • Apache Directory Server：Java实现的LDAP服务

应用场景

  • 企业内部用户认证（VPN、邮箱、OA系统）
  • 组织架构管理
  • 权限控制和用户属性查询

局限性

  1. 安全性差： LDAP 主要是为受信任的内网设计的。虽然有 LDAPS (SSL)，但在公网暴露 LDAP 端口是非常危险的行为。
  2. Web 不友好： LDAP 是基于 TCP 的长连接二进制协议，不是 HTTP。浏览器里的 JavaScript 根本没法直接发 LDAP 请求。
  3. 没有 Token 概念： LDAP 验证完就是验证完了，它不会给你发一个“令牌”让你去访问其他 API。而 OAuth/OIDC 的核心就是那个 Token，可以在微服务之间传递。
  4. 标准化不足： 虽然 LDAP 是标准，但不同厂商（AD vs OpenLDAP）的 Schema（字段定义）差异很大。OIDC/SAML 在这方面屏蔽了底层差异。

LDAP vs. SAML / OIDC / OAuth

  • 本质区别：
    • LDAP 是针对内网设计的、基于 TCP 的查询协议。它很古老，不适合在互联网上裸奔（容易被抓包，且防火墙不友好）。
    • SAML/OIDC 是基于 HTTP/浏览器 的。它们是为了解决 LDAP 无法跨域、无法上云的问题而诞生的。
  • 配合方式：
    • 用户在浏览器用 OIDC 登录 -> 请求发给 IdP（如 Keycloak） -> Keycloak 通过 LDAP 协议去问后端的 AD：“密码对不对？” -> AD 说“对” -> Keycloak 签发 OIDC Token 给用户。

LDAP vs. Kerberos

这是一对焦不离孟的好基友，特别是在 Windows Active Directory (AD) 环境下。

  • 关系：
    • LDAP 负责查信息（这个人属于哪个组？他的邮箱是多少？）。
    • Kerberos 负责验证密码（票据交换，证明你是你）。
  • 区别：
    • LDAP 也可以验证密码（通过 bind 操作），但在 Windows 域环境中，登录过程主要是 Kerberos 在跑，登录成功后，系统会用 LDAP 去拉取你的个人策略、组信息等。
    • Kerberos 极其依赖内网环境和时间同步，出了局域网就基本废了，所以它也没法用于互联网 SSO。

典型应用

  • Windows域环境：AD域的默认认证机制
  • Hadoop集群：大数据平台的安全认证
  • 企业网络：内网资源的安全访问

各协议对比

协议 角色定位 典型“对话”内容 适用范围 是否存放数据?
LDAP 大管家 (数据库) “帮我查下张三的部门” / “密码对不对?” 局域网深处 (后端) 是 (核心数据源)
Kerberos 内网保安 “这是张三的票据(Ticket)，放行吗?” 局域网 (Windows域) 否 (依赖KDC)
SAML 企业信使 “我是IdP，我证明这个XML里的张三已登录” 互联网 / 企业互信 否
OIDC 现代护照 “这是张三的ID Token(JWT)，你自己看” 互联网 / App / SPA 否
OAuth 授权钥匙 “我有令牌，让我进屋拿照片” API 授权 否 
graph TD
    subgraph "前端应用层 (App / Web)"
    A[现代 Web 应用] 
    B[第三方 SaaS 比如 Salesforce]
    end

    subgraph "中间件层 (IdP / 认证中心)"
    C[SSO 平台 比如 Keycloak, Okta, ADFS]
    end

    subgraph "后端存储层 (Source of Truth)"
    D[LDAP 目录服务 比如 AD, OpenLDAP]
    E[SQL 数据库]
    end

    A -- "OIDC / OAuth" --> C
    B -- "SAML" --> C
    C -- "LDAP 协议" --> D

二、Token技术体系

1. Access Token - 资源访问凭证

Access Token 是客户端访问资源服务器的核心凭证，是OAuth 2.0体系的关键组件。

Token格式对比

类型 特点 验证方式 适用场景
不透明Token 随机字符串，无法解析 需调用授权服务器验证 高安全要求的企业环境
JWT Token 自包含，可本地解析 本地验证签名 微服务、分布式系统

生命周期管理

  • 短期有效：通常1小时内过期
  • 续期机制：配合Refresh Token实现自动续期
  • 撤销能力：支持主动撤销和黑名单机制

2. Refresh Token - 令牌续期机制

Refresh Token 专门用于在Access Token过期后获取新的Access Token，实现长期会话管理。

核心特性

  • 长期有效性：7-30天有效期，但可被撤销
  • 存储限制：仅在客户端和授权服务器间流转
  • 单次使用：使用后立即失效，返回新的Refresh Token（Rotation机制）

安全要求

  • HTTPS传输：防止网络传输中被截获
  • 安全存储：客户端需安全存储（如Keychain、Keystore）
  • 撤销机制：支持用户主动撤销或异常检测自动撤销

3. ID Token - 身份信息载体

ID Token 是OpenID Connect的核心组件，以JWT格式承载用户身份信息。

标准声明（Claims）

1
2
3
4
5
6
7
8
9
10
11
{
  "iss": "https://accounts.google.com",        // 发行者
  "sub": "1234567890",                         // 用户唯一标识
  "aud": "your-client-id",                     // 目标客户端
  "exp": 1620000000,                           // 过期时间
  "iat": 1619996400,                           // 签发时间
  "email": "user@example.com",                 // 邮箱
  "email_verified": true,                      // 邮箱验证状态
  "name": "John Doe",                          // 姓名
  "picture": "https://example.com/avatar.jpg"  // 头像
}

安全特性

  • 数字签名：RS256/ES256算法签名，防篡改
  • 时效性：短期有效（通常15-60分钟）
  • 完整性：包含完整的用户身份信息

4. JWT - 自包含令牌标准

JWT（JSON Web Token） 是一种开放标准（RFC 7519），用于在各方之间安全地传输信息。

三段式结构

1
Header.Payload.Signature

详细结构解析

Header（头部）

1
2
3
4
5
{
  "alg": "RS256",    // 签名算法
  "typ": "JWT",      // 令牌类型
  "kid": "key-id"    // 密钥标识
}

Payload（负载）

1
2
3
4
5
6
7
{
  "sub": "user123",           // 主题（用户ID）
  "iat": 1646092800,          // 签发时间
  "exp": 1646096400,          // 过期时间
  "scope": "read write",      // 权限范围
  "aud": "api.example.com"    // 受众
}

Signature（签名）

1
2
3
4
5
RSASHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  private_key
)

算法选择指南

算法 类型 安全性 适用场景
HS256 对称加密 中等 内部微服务
RS256 非对称加密 高 跨域认证
ES256 椭圆曲线 高 移动端应用

安全注意事项

  • 密钥管理：定期轮换签名密钥
  • 算法验证：明确指定允许的签名算法
  • 时效控制：设置合理的过期时间
  • 敏感信息：避免在Payload中包含敏感数据

5. Session Token - 会话状态管理

Session Token 是传统的会话管理机制，通过服务端状态存储维护用户会话。

架构模式

1
2
3
Client (SessionID) ←→ Server (Session Store)
                           ↓
                    Redis/Database/Memory

存储策略

服务端存储

  • 内存存储：性能最优，但不支持集群
  • Redis集群：高性能分布式存储
  • 数据库存储：持久化但性能较低

客户端传输

  • HTTP Cookie：自动传输，支持HttpOnly和Secure标志
  • LocalStorage：手动管理，存在XSS风险

Session vs JWT 对比

特性 Session Token JWT
状态管理 有状态（服务端存储） 无状态（自包含）
扩展性 需要共享存储 天然支持分布式
性能 需要查库验证 本地验证
撤销能力 立即撤销 需要黑名单机制
存储开销 服务端存储成本 网络传输成本

6. SAML 断言 - XML安全声明

SAML断言 是SAML 2.0协议的核心载体，以XML格式承载安全声明信息。

断言类型

认证断言（Authentication Assertion）

1
2
3
4
5
6
7
8
9
<saml:Assertion>
  <saml:AuthnStatement>
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:Password
      </saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
</saml:Assertion>

属性断言（Attribute Assertion）

1
2
3
4
5
6
7
8
<saml:AttributeStatement>
  <saml:Attribute Name="email">
    <saml:AttributeValue>user@company.com</saml:AttributeValue>
  </saml:Attribute>
  <saml:Attribute Name="department">
    <saml:AttributeValue>Engineering</saml:AttributeValue>
  </saml:Attribute>
</saml:AttributeStatement>

授权决策断言（Authorization Decision Assertion）

1
2
3
4
5
<saml:AuthzDecisionStatement Resource="https://app.company.com"
                            Decision="Permit">
  <saml:Action>Read</saml:Action>
  <saml:Action>Write</saml:Action>
</saml:AuthzDecisionStatement>

三、协议与Token协同架构

1. OAuth 2.0 + OpenID Connect 组合

这是现代应用最常用的认证授权组合，同时解决身份认证和资源授权问题。

完整流程

sequenceDiagram
    participant User as 用户
    participant Client as 客户端应用
    participant AuthServer as 认证服务器
    participant Resource as 资源服务器

    User->>Client: 访问应用
    Client->>AuthServer: 重定向到认证页面
    User->>AuthServer: 登录并授权
    AuthServer->>Client: 返回授权码
    Client->>AuthServer: 交换Token
    AuthServer->>Client: 返回Access Token + ID Token
    Client->>Resource: 使用Access Token访问资源
    Client->>AuthServer: 使用Access Token获取UserInfo

技术优势

  • 职责分离：OAuth负责授权，OIDC负责认证
  • 标准化：广泛的行业支持和互操作性
  • 安全性：多层安全机制和最佳实践
  • 灵活性：支持多种客户端类型和场景

2. SAML + LDAP 企业集成

传统企业环境中，SAML和LDAP的组合提供了完整的企业身份管理解决方案。

集成架构

1
2
3
Enterprise AD/LDAP ←→ SAML IdP ←→ SaaS Applications
       ↓                ↓              ↓
   用户目录        身份联邦        业务应用

集成流程

  1. 用户认证：用户通过企业AD/LDAP进行身份验证
  2. 断言生成：IdP生成包含用户属性的SAML断言
  3. 应用授权：SaaS应用验证SAML断言并授权访问
  4. 属性同步：通过LDAP查询获取最新的用户属性

企业价值

  • 统一身份：一套用户目录管理所有应用
  • 合规要求：满足企业安全和合规标准
  • 成本效益：减少重复的身份管理工作

四、安全最佳实践

1. 传输层安全

HTTPS 强制要求

  • 所有Token传输必须使用HTTPS加密
  • 证书验证：确保SSL证书有效性和域名匹配
  • HSTS策略：启用HTTP严格传输安全

Token传输方式

1
2
3
4
5
# ✅ 推荐：Authorization Header
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

# ❌ 避免：URL参数传递
GET /api/user?access_token=eyJhbGciOiJSUzI1NiIs...

2. 存储安全策略

浏览器端安全存储

存储方式 安全性 XSS风险 CSRF风险 推荐场景
HttpOnly Cookie 高 免疫 需防护 传统Web应用
Secure Cookie 高 免疫 需防护 HTTPS环境
LocalStorage 低 高风险 免疫 不推荐存储敏感Token
Memory 最高 免疫 免疫 SPA短期存储

移动端安全存储

1
2
3
4
5
6
7
// iOS - Keychain Services
const keychain = require('react-native-keychain');
keychain.setInternetCredentials('server', 'username', 'token');

// Android - Keystore
import { encrypt, decrypt } from 'react-native-keystore';
encrypt('tokenKey', accessToken);

3. 密钥管理体系

密钥轮换策略

1
2
3
4
5
6
7
8
9
10
11
12
13
JWT签名密钥轮换:
  频率: 每3-6个月
  过程: 
    - 生成新密钥
    - 同时支持新旧密钥验证
    - 逐步淘汰旧密钥
  
密钥存储:
  开发环境: 环境变量
  生产环境: 
    - AWS KMS
    - Azure Key Vault
    - HashiCorp Vault

密钥管理最佳实践

  • 分离存储：密钥与应用代码分离
  • 访问控制：最小权限原则
  • 审计日志：记录所有密钥操作
  • 备份恢复：建立密钥备份和恢复机制

4. 攻击防护机制

重放攻击防护

1
2
3
4
5
6
{
  "jti": "unique-token-id",     // JWT ID，防止重复使用
  "iat": 1646092800,            // 签发时间
  "exp": 1646096400,            // 过期时间
  "nonce": "random-value"       // 随机数，OIDC中使用
}

常见攻击与防护

攻击类型 防护措施 实现方式
Token劫持 HTTPS + Secure Cookie 传输加密
XSS攻击 HttpOnly Cookie + CSP 存储隔离
CSRF攻击 SameSite Cookie + CSRF Token 跨站防护
重放攻击 时间戳 + Nonce + JTI 唯一性验证

五、技术选型指南

场景化选型矩阵

应用场景 推荐协议 Token类型 优势 考虑因素
消费级应用 OAuth 2.0 + OIDC Access Token + ID Token 标准化、易集成 用户体验
企业SSO SAML 2.0 SAML断言 成熟稳定、合规 复杂度较高
移动应用 OIDC + JWT JWT + Refresh Token 离线可用、性能好 存储安全
微服务架构 JWT 自包含JWT 无状态、可扩展 密钥管理
API网关 OAuth 2.0 Bearer Token 细粒度控制 性能要求

现代化选型建议

新项目推荐

  1. OAuth 2.1 + OIDC：现代应用的首选
  2. PKCE扩展：公共客户端必须启用
  3. JWT格式：Access Token使用JWT格式
  4. 短期Token：Access Token 15-60分钟过期

企业级要求

1
2
3
4
5
6
7
8
9
安全要求:
  - SAML 2.0用于企业SSO
  - mTLS用于服务间通信
  - HSM用于密钥存储

合规要求:
  - GDPR: 数据保护和用户同意
  - SOX: 访问控制和审计
  - HIPAA: 医疗数据保护

实施路线图

第一阶段：基础实施

  • 选择认证协议（OAuth 2.0 + OIDC）
  • 部署身份提供商（如Auth0、Okta）
  • 实现基础的登录登出功能
  • 配置HTTPS和基础安全策略

第二阶段：安全加固

  • 启用多因素认证（MFA）
  • 实施Token轮换和撤销
  • 配置安全存储和传输
  • 建立监控和审计机制

第三阶段：高级特性

  • 细粒度权限控制（RBAC/ABAC）
  • 跨域SSO集成
  • 零信任架构实施
  • 持续安全评估

六、技术发展趋势

新兴技术标准

OAuth 2.1

OAuth 2.1整合了OAuth 2.0的安全最佳实践，主要改进包括：

  • 强制PKCE：所有公共客户端必须使用PKCE
  • 移除隐式流：不再支持隐式授权模式
  • 刷新令牌安全：强化Refresh Token的安全要求

WebAuthn (FIDO2)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// WebAuthn注册示例
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: new Uint8Array(32),
    rp: { name: "Example Corp" },
    user: {
      id: new TextEncoder().encode("user123"),
      name: "user@example.com",
      displayName: "John Doe"
    },
    pubKeyCredParams: [{alg: -7, type: "public-key"}],
    authenticatorSelection: {
      authenticatorAttachment: "platform",
      userVerification: "required"
    }
  }
});

零信任架构下的认证

动态授权模型

1
2
3
4
5
6
7
8
9
零信任原则:
  - 永不信任，始终验证
  - 最小权限访问
  - 持续验证和监控

实施策略:
  - 基于风险的自适应认证
  - 上下文感知的访问控制
  - 实时威胁检测和响应

标准参考文档

RFC标准

  • RFC 6749: OAuth 2.0 Authorization Framework
  • RFC 7519: JSON Web Token (JWT)
  • RFC 7636: Proof Key for Code Exchange (PKCE)
  • RFC 8414: OAuth 2.0 Authorization Server Metadata

安全框架

  • OWASP API Security Top 10: API安全最佳实践
  • NIST Cybersecurity Framework: 网络安全框架
  • ISO 27001: 信息安全管理体系标准

总结

认证和授权技术体系正在快速发展，从传统的Session管理到现代的JWT和OAuth体系，再到新兴的零信任架构，技术选择需要综合考虑安全性、可用性、可扩展性等多个维度。

关键要点：

  1. OAuth 2.0 + OIDC 是现代应用的主流选择
  2. JWT 在微服务架构中具有显著优势
  3. SAML 在企业环境中仍然重要
  4. 安全性 始终是第一考虑因素
  5. 标准化 有助于系统集成和维护

选择合适的认证授权方案，需要基于具体的业务场景、技术架构和安全要求进行综合评估。