3.3 通信与认证授权

3.3 通信与认证授权

本节摘要：SOURCE 3.4–3.5：通信必须 TLS 1.2+、验证证书、可选 Pinning；认证授权必须在服务端执行，客户端只持短期 Token。本节含 OkHttp CertificatePinner 与 OAuth2 Refresh Rotation 要点。

读前必看

1. 配置 Network Security Config 与 ATS
2. 实现 SPKI Pinning 及证书轮换策略
3. 设计 Access/Refresh + MFA 流程

一、HTTPS 基线

• 禁明文 HTTP（Android NSC / iOS ATS）
• 禁 TLS 1.0/1.1；优先 TLS 1.2+
• 验证主机名与完整证书链

<!-- res/xml/network_security_config.xml -->
<domain-config>
  <domain includeSubdomains="true">api.example.com</domain>
  <pin-set expiration="2027-01-01">
    <pin digest="SHA-256">base64+primary=</pin>
    <pin digest="SHA-256">base64+backup=</pin>
  </pin-set>
</domain-config>
​

OkHttp：

CertificatePinner.Builder()
    .add("api.example.com", "sha256/PRIMARY_HASH")
    .add("api.example.com", "sha256/BACKUP_HASH")
    .build()
​

轮换：Pin 至少两个 SPKI（当前 + 下一证书），expiration 前发版更新。

TLS 与 Pinning 链路

TLS 与 Pinning 链路

二、API 安全

• 敏感参数放 POST body，不放 URL Query（防日志泄露）
• 移动端 API 需 rate limit + 设备指纹
• GraphQL 注意 introspection 与批量查询 DoS

三、认证：服务端裁决

反模式：客户端 if (pin == "1234") 解锁功能。

正模式：

1. 用户提交凭据 → 服务端验证
2. 返回 Access Token（15min）+ Refresh（7d，HttpOnly 若 Web；移动端加密存 Keychain）
3. 敏感操作要求 MFA（TOTP/WebAuthn/短信二次 — 短信弱于 TOTP）

四、授权与 IDOR

每个 /orders/{id} 必须服务端验证 id 属于当前 sub。客户端传的 userId 不可信。

Refresh Rotation：每次 refresh 签发新 refresh，旧 refresh 作废 — 检测重放盗窃。

⚠️ 常见坑：Pinning 只 Pin 叶子证书 — 换 CA 重签后全量用户崩溃；应 Pin SPKI。

💡 关键直觉：客户端是不可信终端 — 所有安全决策在服务端做，Token 只是证明。

核心回顾

• TLS + Pinning（双 SPKI + expiration）防 MITM
• OAuth2 式短 Access + Refresh Rotation
• MFA 用于支付/改密等高风险操作
• IDOR 用自动化用例覆盖

第 4 章用 SAST/DAST 与逆向验证本章实现。

深化：TLS 与 Pinning 的工程细节

HTTPS 基线要检查三件事：协议版本（TLS 1.2+，禁 1.0/1.1）、证书链校验（系统信任库 + 主机名）、传输内容（敏感数据在 body 而非 URL）。Pinning 用于关键域名：把服务端证书的 SPKI 哈希写进客户端，只有哈希匹配才放行。Pinning 双哈希是标准做法：当前证书 + 下一张证书，避免轮换时全量用户崩溃。

// OkHttp 双哈希 Pinning（示意）
CertificatePinner.Builder()
    .add("api.example.com", "sha256/PRIMARY_HASH", "sha256/BACKUP_HASH")
    .build()
// 注意：Pinning 要在服务端证书更换前发版更新
​

认证授权必须服务端裁决：客户端只持短期 Access Token，密码与 MFA 校验都在服务端。Refresh Token 用轮换机制，每次刷新签发新 refresh 并作废旧值，能检测重放盗窃。IDOR 的修复是「资源归属校验」：每个 /orders/{id} 都验证该 id 属于当前主体，客户端传参一律不可信。

认证流程的端到端设计

把登录、会话、注销三段串起来看：登录时客户端只提交凭据，密码校验与 MFA 在服务端完成；成功后签发短期 Access Token 与可轮换的 Refresh Token，敏感操作再要求二次验证；注销时服务端吊销所有 Token，客户端清除本地存储并保留可验证证据。三段里最容易漏的是「注销后的会话失效」——服务端若没有吊销能力，客户端删了本地 Token 也只是掩耳盗铃。

# 会话生命周期（示例）
登录 -> 服务端校验+MFA -> 签发 access(15min)+refresh(7d)
访问 -> Bearer access -> 服务端 RBAC 校验
刷新 -> 旧 refresh 换新 refresh（旧值作废）-> 检测重放
注销 -> 服务端吊销 + 本地清除 -> 旧 token 调 API 返回 401
​

MFA 的选择按风险定级：支付、改密、换绑这类高危操作要求 TOTP 或 WebAuthn；普通登录可视风险用短信验证，但要认识到短信存在被劫持的可能。一切规则都在服务端执行，客户端只是用户交互的入口。