网络安全：认证与授权知识体系

认证（Authentication, AuthN）与授权（Authorization, AuthZ）是网络安全体系的核心基石，二者共同构成系统访问控制的第一道防线。认证解决"你是谁"的身份校验问题，授权解决"你能做什么"的资源访问问题，认证是授权的前提，授权是认证的目标。

以下从核心基础、协议标准、权限模型、组合架构、安全实践、选型对比六个维度，对OAuth2.0、JWT、SSO、RBAC/ABAC进行系统性结构化梳理。

一、核心基础概念与分层架构

现代分布式系统的认证授权体系通常分为三层，各层职责解耦：

核心设计原则：最小权限原则、职责分离原则、可审计可追溯原则、零信任原则（永不信任，始终验证）。

二、核心协议与令牌标准

2.1 OAuth 2.0 授权框架

定位：授权框架，而非认证协议。解决"第三方应用在不获取用户账号密码的前提下，安全访问用户受保护资源"的问题，是开放平台、分布式系统的事实授权标准。

核心四角色

• 资源所有者（Resource Owner）：终端用户，拥有资源访问权限
• 客户端（Client）：第三方应用，请求访问资源的主体
• 授权服务器（Authorization Server）：负责验证身份、颁发授权令牌
• 资源服务器（Resource Server）：存放受保护资源，校验令牌后提供服务

四种标准授权模式

关键扩展与机制

• PKCE（授权码增强）：防止授权码拦截攻击，适配移动端、单页应用等无后端场景
• Refresh Token：刷新令牌，用于Access Token过期后无感刷新，减少用户重复授权
• Scope机制：权限范围控制，细化第三方应用可访问的资源边界，遵循最小权限原则

核心局限

仅定义授权流程，不定义标准的用户身份信息格式，无法独立完成身份认证。

2.2 JWT（JSON Web Token）

定位：开放标准的令牌格式，用于在多方之间安全传输JSON格式的声明信息，通常作为认证与授权的信息载体。

令牌结构（三段式，点分隔）

1. Header（头部）：声明令牌类型、签名算法（如HS256对称加密、RS256非对称加密）
2. Payload（载荷）：存放声明（Claims），包括：
   • 标准声明：iss（签发者）、exp（过期时间）、sub（主题）、aud（受众）
   • 自定义声明：用户ID、角色、权限等业务信息
3. Signature（签名）：对前两段内容的数字签名，防止篡改，验证令牌完整性与合法性

工作流程

用户登录成功 → 认证服务器生成JWT并签名 → 客户端存储JWT → 请求时携带在Authorization: Bearer <token>中 → 资源服务器验签后解析身份与权限

核心特性

• 优势：无状态（服务端无需存储会话）、天然支持分布式微服务、跨语言通用、自包含信息减少数据库查询
• 劣势：无法主动作废（过期前始终有效）、载荷明文传输不可存敏感信息、体积大于Session ID

常见误区

• JWT ≠ OAuth2.0：JWT是令牌格式，OAuth2.0是授权流程框架，二者可组合也可独立使用
• JWT不是加密技术：仅做签名防篡改，不做内容加密

2.3 SSO（Single Sign-On 单点登录）

定位：认证架构方案，用户在统一认证中心登录一次，即可无需重复认证访问所有互信的业务系统。

核心原理

引入统一身份提供方（Identity Provider, IdP），所有业务系统（Service Provider, SP）信任IdP签发的身份断言，实现跨系统身份共享。

主流实现方案

1. 同域SSO
   • 基于Cookie共享机制，适合同一根域名下的多个子系统
   • 实现简单，依赖Cookie的Domain属性共享会话ID
2. 跨域SSO
   • CAS协议：经典企业级SSO协议，通过TGT（票据授予票据）和ST（服务票据）两级票据机制实现，服务端存储会话
   • OIDC/OAuth2.0架构：现代互联网主流方案，IdP基于OAuth2.0颁发身份令牌，天然支持跨域、移动端、第三方接入
   • SAML 2.0：基于XML的联邦身份协议，多用于政府、大型企业跨组织SSO

核心风险

单点故障：IdP崩溃将导致所有业务系统无法登录；账号泄露影响范围覆盖所有接入系统。

三、权限控制模型

3.1 RBAC（Role-Based Access Control 基于角色的访问控制）

核心思想：权限绑定角色，角色绑定用户，用户通过角色间接获得权限，是目前应用最广泛的粗粒度权限模型。

NIST标准四层模型

• RBAC0（核心模型）：用户-角色-权限多对多映射，最基础实现
• RBAC1（角色继承）：角色间上下级继承关系，上级自动拥有下级所有权限
• RBAC2（角色约束）：增加角色互斥、基数约束、先决条件等规则（如财务和审计角色不可兼任）
• RBAC3（统一模型）：RBAC1 + RBAC2的完整集合

适用评估

• 优势：简单直观、易于实施、批量管理效率高、审计友好，适配企业组织结构
• 劣势：角色膨胀问题（业务复杂度上升时角色数量指数增长）、细粒度不足、无法支持动态上下文权限
• 典型场景：中后台管理系统、企业内部系统、组织结构稳定的业务

3.2 ABAC（Attribute-Based Access Control 基于属性的访问控制）

核心思想：通过策略规则组合多维度属性，动态决策是否授权，是细粒度动态权限的主流方案。

核心三属性维度

1. 主体属性：用户ID、角色、部门、职级、安全等级、账号状态
2. 客体属性：资源类型、所属部门、敏感级别、创建者、数据标签
3. 环境属性：访问时间、地理位置、IP地址、设备类型、请求频率、操作风险等级

核心组件

• PAP（策略管理点）：策略配置与管理
• PDP（策略决策点）：接收请求，匹配规则输出决策
• PEP（策略执行点）：拦截请求，向PDP申请决策并执行
• PIP（策略信息点）：提供属性数据查询

适用评估

• 优势：极致细粒度、动态上下文感知、灵活性高（新增规则无需改代码）、适配复杂业务场景
• 劣势：实现复杂度高、策略引擎性能开销大、规则爆炸维护难、审计追溯困难
• 典型场景：金融医疗等高安全行业、云原生微服务、数据级权限管控、动态业务环境

四、技术组合与典型架构

4.1 经典组合：OAuth2.0 + JWT + RBAC

• 适用场景：分布式微服务、开放平台、SaaS应用
• 协作流程：
  1. OAuth2.0完成授权流程，确保第三方应用合法接入
  2. 授权服务器签发JWT令牌，载荷中携带用户角色信息
  3. 资源服务验签JWT，通过RBAC模型校验接口/资源权限
• 优势：无状态、易扩展、天然支持分布式部署

4.2 企业级组合：SSO（OIDC） + ABAC

• 适用场景：大型企业、多云环境、多系统联邦
• 协作流程：
  1. OIDC协议实现跨系统SSO，统一身份认证入口
  2. IdP返回包含丰富用户属性的ID Token
  3. 各业务系统通过ABAC策略引擎，结合上下文动态鉴权
• 优势：统一身份管理、细粒度权限、适配复杂组织架构

4.3 OIDC：认证+授权一体化标准

OIDC（OpenID Connect）是OAuth2.0的认证层扩展，在授权框架之上增加了标准身份定义，同时解决认证与授权问题：

• 新增ID Token（JWT格式）：标准化用户身份信息
• 新增UserInfo端点：获取更详细的用户资料
• 是现代SSO、身份云的事实标准

五、安全风险与最佳实践

5.1 OAuth2.0 安全

• 核心风险：授权码劫持、CSRF攻击、重定向URI绕过、Scope权限过大、令牌泄露
• 最佳实践：
  • 强制使用PKCE增强授权码模式安全性
  • 校验state参数防御CSRF
  • 严格配置redirect_uri白名单，禁止通配符
  • 遵循最小Scope原则，令牌设置短有效期

5.2 JWT 安全

• 核心风险：签名算法降级攻击、密钥泄露、重放攻击、敏感信息明文存储
• 最佳实践：
  • 优先使用非对称加密签名（RS256），避免对称密钥泄露风险
  • 设置合理过期时间，敏感操作强制二次校验
  • 载荷禁止存放密码、手机号等敏感信息，全程HTTPS传输
  • 关键场景配合黑名单机制，实现令牌主动作废

5.3 权限模型通用实践

• 采用RBAC为基础 + ABAC做动态增强的混合模式，兼顾易用性与灵活性
• 严格遵循最小权限原则，定期审计权限，回收冗余权限
• 所有权限操作留痕，支持全链路审计追溯

六、技术选型对比总结

RBAC vs ABAC 核心对比

Session Cookie vs JWT 对比

七、总结

认证授权体系是一个从"身份验证"到"令牌传递"再到"权限决策"的完整链路：

1. 入口层：通过SSO统一身份入口，解决多系统登录体验
2. 协议层：通过OAuth2.0/OIDC完成授权流程，解决第三方与跨系统信任
3. 载体层：通过JWT传递身份与权限信息，解决分布式无状态问题
4. 决策层：通过RBAC/ABAC模型完成最终的资源访问控制，保障数据安全

实际落地中需根据业务规模、安全等级、技术架构选择合适的技术组合，而非盲目追求最复杂的方案。

附：《认证授权：时序图 + 微服务网关鉴权落地架构》

包含：OAuth2.0授权码模式(PKCE)时序、OIDC‑SSO时序、JWT网关鉴权流程、RBAC+ABAC混合落地架构、伪代码示例、常见坑点

一、OAuth2.0 授权码模式 + PKCE（现代主流）时序

场景：SPA/移动端，无后端服务，PKCE防止授权码劫持
角色：浏览器客户端、授权服务器AS、资源服务器RS

sequenceDiagram
    participant Client as SPA/移动端客户端
    participant AS as 授权服务器(AS)
    participant RS as 资源服务器(RS)

    Note over Client: 1. 本地生成 code_verifier / code_challenge
    Client->>AS: 2. 跳转授权接口<br/>response_type=code<br/>code_challenge=xxx<br/>code_challenge_method=S256<br/>client_id、redirect_uri、scope、state
    AS->>用户: 3. 用户登录 + 授权确认页面
    用户-->>AS: 4. 用户确认授权
    AS-->>Client: 5. 重定向回调，返回 authorization_code + state
    Note over Client: 校验state，防CSRF
    Client->>AS: 6. 请求token接口<br/>grant_type=authorization_code<br/>code=授权码<br/>code_verifier=原始verifier<br/>client_id
    AS->>AS: 校验code、code_verifier合法性
    AS-->>Client: 7. 返回 AccessToken + RefreshToken
    Client->>RS: 8. 业务API请求，Header: Authorization: Bearer AccessToken
    RS->>RS: 校验token签名/过期/scope
    RS-->>Client: 9. 返回受保护资源

关键点：

1. PKCE：code_challenge传给AS，code_verifier留在客户端，交换token时提交；攻击者拿到授权码没有verifier拿不到token
2. state参数：防止CSRF，请求时随机生成，回调必须原样带回校验
3. AccessToken短时效；RefreshToken用于静默刷新AccessToken

二、OIDC SSO 单点登录完整时序（OAuth2 + ID‑Token，企业SSO）

OIDC = OAuth2 + 身份认证，输出JWT格式ID‑Token，实现一次登录多系统访问
角色：用户浏览器、IdP统一身份中心、SP业务应用A、SP业务应用B

sequenceDiagram
    participant Browser as 用户浏览器
    participant IdP as IdP身份中心(OIDC)
    participant SPA as 业务系统A(SP‑A)
    participant SPB as 业务系统B(SP‑B)

    Note over Browser,SPA: 用户访问业务A，未登录
    SPA-->>Browser: 302重定向到IdP授权端点
    Browser->>IdP: OIDC授权请求 client_id、scope=openid profile email、redirect_uri、state、nonce
    alt IdP无会话
        IdP->>Browser: 展示登录页面
        Browser-->>IdP: 提交账号密码，IdP建立IdP全局session
    end
    IdP-->>Browser: 重定向回调SP‑A，返回 authorization_code
    Browser->>SPA: 回调携带code
    SPA->>IdP: /token接口，使用code换取令牌
    IdP-->>SPA: 返回 AccessToken、ID‑Token(JWT)、RefreshToken
    Note over SPA: 解析ID‑Token拿到sub(用户id)、用户信息；建立SP本地会话
    SPA-->>Browser: 登录成功，设置业务A本地cookie

    Note over Browser,SPB: 用户新开标签访问业务B，未登录
    SPB-->>Browser: 重定向IdP授权端点
    Browser->>IdP: OIDC授权请求
    Note over IdP: IdP已有全局登录会话，无需再次输密码
    IdP-->>Browser: 重定向回调SP‑B，返回authorization_code
    Browser->>SPB: 回调携带code
    SPB->>IdP: /token换取ID‑Token
    IdP-->>SPB: 返回令牌
    Note over SPB: 解析ID‑Token完成登录，建立业务B会话
    SPB-->>Browser: 业务B登录成功

重要：nonce 用于防御ID‑Token重放攻击；scope=openid 是OIDC标志，没有就只是普通OAuth2授权。

三、微服务网关鉴权架构（OAuth2 + JWT + Gateway，生产落地）

架构分层

客户端(Web/App)
     ↓ HTTPS
API网关（Gateway / Spring Cloud Gateway / Kong）
├─①令牌校验层：JWT验签、过期、黑名单校验
├─②身份解析层：从JWT提取 sub、roles、自定义属性
├─③鉴权决策层：RBAC基础权限 + ABAC动态策略
└─④路由转发：透传用户身份信息给后端微服务
     ↓
业务微服务A / B / C

网关内部处理时序

sequenceDiagram
    participant Client
    participant Gateway as API网关
    participant Redis as Redis(JWT黑名单/刷新令牌存储)
    participant PDP as 权限决策服务(RBAC+ABAC)
    participant Service as 后端业务微服务

    Client->>Gateway: HTTP API，Header: Bearer JWT
    Gateway->>Gateway: 1.提取token，校验格式
    Gateway->>Redis: 2.查询token是否在黑名单(注销/踢出场景)
    alt 黑名单 / 签名错误 / 过期
        Gateway-->>Client: 401 Unauthorized
    else 校验通过
        Gateway->>Gateway: 3.解析JWT payload：userId、roles、dept
        Gateway->>PDP: 4.鉴权请求：userId，访问接口url，httpMethod，ip，时间等属性
        PDP->>PDP: RBAC角色匹配 + ABAC属性策略判断
        alt 拒绝访问
            PDP-->>Gateway: deny
            Gateway-->>Client: 403 Forbidden
        else 允许访问
            PDP-->>Gateway: allow
            Note over Gateway: 将userId、roles放入请求Header向下游透传
            Gateway->>Service: 转发请求 X‑User‑Id、X‑User‑Roles
            Service-->>Gateway: 业务响应
            Gateway-->>Client: 返回结果
        end
    end

架构要点：

1. 鉴权尽量前置到网关，微服务只做业务数据权限；网关只做接口级访问控制
2. JWT本身不能主动失效，Redis黑名单解决登出、强制踢人；只存未过期token，TTL与token过期一致，不长期占存储
3. 下游微服务不要二次解析JWT，信任网关透传的请求头；内网网络隔离，防止头伪造
4. AccessToken短生命周期（5‑15min），RefreshToken存在后端，不要下发到前端localStorage（优先HttpOnly Cookie）

网关JWT校验伪代码（Java风格）

// 1. 取出Bearer token
String token = extractBearerToken(request);
if(token == null) return 401;

// 2. 验签（非对称RS256，公钥验签，私钥仅AS持有）
Jws<Claims> jws = jwtParser.parseClaimsJws(token);
Claims payload = jws.getBody();

// 3. 基础时间校验
Date now = new Date();
if(payload.getExpiration().before(now)) return 401;

// 4. 黑名单校验（登出/强制下线）
if(redis.hasBlackList(token)) return 401;

// 5. 提取身份属性
String userId = payload.getSubject();
List<String> roles = payload.get("roles", List.class);

// 6. 调用PDP权限决策服务
AuthDecision decision = pdp.check(userId, request.getUrl(), request.getMethod(), request.getIp());
if(!decision.isAllow()){
    return 403;
}

// 7. 设置透传header，转发给微服务
exchange.getRequest().mutate()
        .header("X‑User‑Id", userId)
        .header("X‑User‑Roles", String.join(",", roles));

四、RBAC + ABAC 混合权限模型落地架构（生产最常用）

纯RBAC会角色爆炸；纯ABAC太重；工程上：RBAC做接口功能权限，ABAC做数据/上下文权限

模型结构

1. RBAC层（功能接口权限）
   用户 <--多对多--> 角色 <--多对多--> 权限码（接口/功能码：user:list, user:add）

控制：这个用户能不能调用【用户列表】接口

1. ABAC层（数据级、动态上下文）
   输入四元组：

• 主体属性：userId、roles、deptId、securityLevel
• 资源客体：resourceType、ownerId、dataDept、dataSecurityLevel
• 环境属性：accessTime、clientIp、device、riskLevel
• 操作：read/write/delete

策略示例：

if ( 用户部门 == 数据所属部门 ) AND (时间 9‑18点) AND (安全等级>=数据密级) → allow else deny

PDP权限决策逻辑伪代码

public AuthDecision check(String userId, String api, String resourceId, ContextEnv env){
    // 第一步 RBAC：功能接口是否有权限
    boolean rbacOk = rbacService.hasPermission(userId, api);
    if(!rbacOk){
        return AuthDecision.deny("无接口功能权限");
    }

    // 第二步 ABAC：数据/上下文策略
    SubjectAttr subject = attrProvider.getSubject(userId);
    ObjectAttr resource = attrProvider.getResource(resourceId);
    boolean abacOk = abacPolicyEngine.evaluate(subject, resource, env);
    if(!abacOk){
        return AuthDecision.deny("数据权限不满足策略");
    }
    return AuthDecision.allow();
}

职责划分：

• 网关层：执行RBAC接口级鉴权
• 业务服务层：执行ABAC数据行级鉴权（过滤SQL数据，行过滤）

五、高频踩坑清单（生产避坑）

OAuth2/OIDC

1. redirect_uri 不要写通配符，必须白名单严格匹配，防止跳转劫持
2. SPA不要用Implicit简化模式，一律授权码+PKCE
3. state/nonce必须校验，不要省略
4. scope最小化，不要直接给全部scope

JWT

1. 不要把密码、身份证明文放payload；payload只是base64，不是加密
2. HS256对称密钥泄露=全部token可伪造；多服务场景优先RS256非对称
3. 登出不能只删前端token，必须黑名单；token有效期不能设置几天这种长时效
4. 禁止alg:none算法，关闭该解析能力

SSO

1. IdP单点故障降级预案；会话有效期合理设置
2. SSO登录后，业务系统也要做会话管控，不能完全信任IdP

RBAC+ABAC

1. 不要把数据权限全部塞到JWT payload，payload不宜过大；数据属性实时查询PIP
2. ABAC策略数量爆炸，要有策略版本、开关、审计日志
3. 权限一定要可审计：每一次deny/allow都记录日志：userId、资源、策略id、结果

六、补充：技术选型决策树（快速判断）

1. 单体传统Web应用 → Session‑Cookie
2. 前后端分离/微服务API，无第三方登录 → JWT + RBAC
3. 需要第三方登录（微信/企业微信）→ OAuth2.0授权码+PKCE
4. 多系统统一登录（内部多业务）→ OIDC‑SSO
5. 接口功能权限：RBAC；需要数据行级、IP/时间动态规则 → RBAC+ABAC混合