现代身份认证与访问控制

• 授权码流程
• PKCE 的 code_verifier/code_challenge
• 授权码拦截防御

OAuth 2.0 授权码流程：客户端引导用户授权，授权服务器返回授权码，客户端用授权码 + client_secret 兑换 token。PKCE（RFC 7636）在不依赖 client_secret 的情况下防止授权码拦截：客户端先生成随机 code_verifier，计算 code_challenge（S256 哈希或 plain）随授权请求发送；换 token 时附上 code_verifier，授权服务器校验 code_challenge 与 code_verifier 匹配。若授权码被拦截，拦截者没有 code_verifier，无法兑换 token。工程机制上，即使 attacker 拿到授权码，缺少 verifier 就无法完成兑换，从而防御授权码拦截。

PKCE 把"授权码与请求者绑定"作为防护核心。对公共客户端（无 secret）是必需，对机密客户端也是深度防御。OAuth 2.1 强制要求 PKCE。

• ID Token 的 JWT 结构与签名
• nonce 防重放
• aud、iss 验证

OIDC 在 OAuth 2.0 之上增加身份层，返回 ID Token（JWT）携带用户身份信息（sub、profile 等）。验证要点：1）用授权服务器（OP）的 JWK 验证 ID Token 的签名，确保来自可信的 OP；2）验证 iss 与期望的 OP 一致；3）验证 aud 包含自己的 client_id，防止 token 被其他客户端使用；4）验证 nonce 与发起认证时发送的 nonce 一致，防止重放攻击；5）验证 exp 未过期。合规的验证还需按 OIDC Discovery（.well-known/openid-configuration）获取 OP 的配置与 JWKS。

ID Token 是"身份断言"，其安全性依赖签名验证与声明组合校验。iss 验证来源、aud 验证受众、nonce 防重放、exp 防过期，缺一不可。

• 算法混淆
• kid 注入
• 防御实践

JWT 的安全风险包括：alg=none 攻击（攻击者把 alg 改为 none 并删除签名，若服务器被迫接受则伪造 token）；算法混淆（如把 RS256 改为 HS256，用公开的 RSA 公钥作为 HMAC 密钥验证，攻击者可自行签名）；kid 注入（kid 是 JWK 的密钥标识，攻击者可注入 kid 指向攻击者控制的密钥或路径）。防御实践：服务端固定允许的算法白名单并拒绝 none、在解码前明确校验算法与密钥类型匹配、服务端验证 kid 对应可信密钥且不解析不可信路径、使用库的安全默认（如仅允许 RS256/ES256/EdDSA）、强制校验 JWT 的签名与声明。

根因是"信任 header 中的 alg/kid"。防御核心是服务端"不信任客户端声明"，固定算法与密钥绑定，严格校验。

• WebAuthn 注册/认证流程
• Attestation 与 Assertion
• 硬件密钥集成

WebAuthn 提供无密码认证。注册（registration）时，服务器生成随机 challenge，客户端用 authenticator（如 YubiKey、Touch ID）生成新的非对称密钥对，公钥注册到服务器，私钥保存在 authenticator，并返回 Attestation（证明公钥由可信 authenticator 生成）。认证（assertion）时，服务器发新 challenge，authenticator 用私钥签名返回 Assertion（签名+challenge），服务器用注册的公钥验签。硬件密钥（YubiKey）集成：密钥在硬件内，私钥不出硬件，可绑定用户与的 PIN/生物识别，防止钓鱼（凭证绑定到特定 origin）。工程上须校验 origin、challenge、签名、以及可选的 attestation 信任链。

WebAuthn 的核心是"私钥不出硬件 + challenge 绑定 origin"，天然抗钓鱼与重放。Attestation 证明硬件真实性，Assertion 完成认证。它与 CTAP（硬件传输）配合构成 FIDO2。

• Passkey 的同步机制
• 各平台实现差异
• 跨平台兼容

Passkey 是 WebAuthn 凭证的跨设备同步形式。实现差异：iCloud Keychain（Apple）通过 iCloud 同步 Passkey 并绑定 Apple ID，在 Apple 生态无缝；Google Password Manager 在 Android/Chrome 同步；1Password、Bitwarden 等密码管理器通过自己的加密保险库同步 Passkey（B2B 方案，如 Bitwarden 的 Passkey sync）。跨平台兼容指 Passkey 可通过多平台（FIDO 联盟的 iCloud/Google/微软通行）同步，用平台提供的认证器跨设备使用。差异核心是"同步存储与信任模型"：平台内置（iCloud/Google）依赖生态绑定，第三方管理器依赖加密保险库与导入导出。兼容性挑战在于凭证格式与 discovery 的跨平台握手。

Passkey 的"同步"与"设备绑定"是两种形态：同步型（synced）跨设备、备份云端；设备绑定型（device-bound）仅存于单设备。跨平台兼容依赖 FIDO 联盟的联合与平台 Passkey 支持。

• 算法混淆原理
• HS256/RS256 混淆
• 防御

JWT 算法混淆攻击：攻击者把 token 的 alg 从非对称算法（如 RS256）改成对称算法（HS256），使服务器用非对称算法的公钥（公开）作为 HMAC 的密钥去验证。由于公钥公开，攻击者可用公钥自行构造 HS256 签名，伪造有效 token。类似地，攻击者可能把 alg 改为服务器不支持的算法。防御：服务器固定允许的算法白名单（如只允许 RS256/ES256/EdDSA）、不信任 token 中的 alg、验证时明确将密钥类型与算法绑定（JWK 中指定 kty）、拒绝 none 与强对称算法、使用库的受控配置。核心是"算法由服务端决定，而非 token 声明"。

根因是"信任客户端 alg 声明"。防御必须把算法与密钥类型绑定，并设置算法白名单，使攻击者无法切换算法。

• 三种授权类型
• 适用场景
• 安全差异

OAuth 2.0 授权类型：Authorization Code（授权码）适用于有用户交互的 Web/移动应用，用户授权后返回授权码再换 token，配合 PKCE 安全；Client Credentials（客户端凭证）适用于无用户的机器对机器（M2M）场景，客户端用 secret 直接换 token，代表应用自身；Device Code（设备码）适用于无浏览器/输入受限的设备（如智能电视、CLI），用户在一个设备上输入设备码并授权，另一设备完成认证。三种类型差异在"是否涉及用户授权"与"交互方式"：授权码有用户、client credentials 无用户、device code 有用户但输入受限。

授权类型选择取决于"是否有用户交互"与"客户端能力"。授权码最安全（用户参与），client credentials 适合服务间，device code 适合无浏览器设备。OAuth 2.1 弃用 Implicit，推荐授权码 + PKCE。

• ID Token 签名验证
• nonce 防重放
• 声明校验

OIDC 的 ID Token 是 JWT，客户端用 OP 的公钥（通过 JWKS 获取）验证签名，确认 token 由可信 OP 签发，防止伪造。nonce 防重放：客户端在发起认证请求时生成随机 nonce 并随请求发送，OP 在 ID Token 中回显该 nonce，客户端验证返回的 nonce 与发起时一致，从而防止攻击者重放旧 ID Token（重放攻击）。此外还需验证 iss、aud、exp 等。工程上通过 OIDC Discovery 获取 OP 配置与 JWKS，用标准库验证。

签名验证保证"来源可信"，nonce 保证"本次会话新鲜"。重放攻击因 nonce 逐次不同而被拦截，是防重放的关键机制。

• FIDO2 的组成
• WebAuthn 与 CTAP
• SAML 的关系

FIDO2 由 WebAuthn（浏览器/平台 API）与 CTAP（Client to Authenticator Protocol）组成。WebAuthn 是浏览器与依赖方（RP）之间的 Web API，负责与网页交互、管理浏览器侧认证流程；CTAP 是浏览器与外部 authenticator（如 YubiKey）之间的协议，传输 WebAuthn 命令。SAML 是另一套基于 XML 断言的身份联邦协议（不同于 FIDO2），用于单点登录（SSO），与 WebAuthn 可互补：SAML 处理身份会话与联邦，WebAuthn 提供无密码的强认证因子。协议栈层次：WebAuthn（浏览器层）+ CTAP（authenticator 传输层）+ authenticator（硬件），而 SAML 属于应用层身份联邦。

WebAuthn 处于"浏览器-服务器"层，CTAP 是"浏览器-硬件"层，二者共同构成 FIDO2。SAML 是独立的应用层协议，可结合 WebAuthn 做强认证。

• attestation 类型
• 各类型的信任链
• 工程信任决策

WebAuthn attestation 证明"私钥由可信 authenticator 生成"。不同类型：basic（basic attestation）用 authenticator 的证书（ICA 证书）直接证明，信任链到设备厂商；self（self attestation）用 authenticator 自己的密钥自证，无外部信任锚，信任度低；attca（attestation CA）用 CA 签发的证书，信任链到 CA；anonca（anonymity CA）用匿名 CA 签发一次性证书，保护用户隐私同时证明 authenticity。工程信任链：服务端验证 attestation 证书链是否到可信 CA/厂商，决定是否信任该 authenticator。basic/attca 有明确信任链，self 信任度低，anonca 在隐私与信任间平衡。

attestation 的信任链决定"是否接受该设备"。basic/attca 依赖厂商/CA 证书，self 仅自证，anonca 在隐私与信任间平衡。服务端应在注册时校验 attestation 类型与信任链，并可选择忽略 attestation 而以 FIDO 断言（如 possession）作为认证依据。

• challenge 的随机性与防重放
• authenticator 生成签名断言的流程
• 服务端验证的要点

WebAuthn assertion（认证）流程：服务端生成随机 challenge（一次性随机数）与客户端选项，发送给客户端；客户端调用 authenticator（如 YubiKey、Touch ID），authenticator 用私钥对 challenge 与客户端数据（clientData、authenticatorData）签名，生成 assertion；客户端把 assertion 返回服务端；服务端用该用户注册时的公钥验证签名、校验 challenge 是否与本次一致（防重放）、校验 RP ID 与 origin、检查签名计数器（防克隆）。challenge 是认证的"一次性随机挑战"，防止重放攻击；signature 证明"持有私钥"；verification 确认身份与完整性。

challenge 是防重放的核心，每次认证必须新鲜且唯一。assertion 用私钥签名证明"你拥有该凭证"，服务端用公钥验证并核对 challenge、origin、计数器，构成完整的持证认证。

• mTLS 的双向认证
• Service Mesh 中的自动认证
• 零信任的信任边界

mTLS（双向 TLS）要求客户端与服务器都出示证书、互相验证身份，不仅服务端认证客户端，客户端也认证服务端，从而建立双向身份信任。在服务网格（如 Istio、Linkerd）中，mTLS 由 sidecar 代理自动注入证书并进行双向认证，服务间通信默认加密且身份互认，实现"服务身份"认证。在零信任网络中，mTLS 是"永不信任、始终验证"的落地手段：每个请求都验证调用方身份、授权与加密，消除对网络边界的信任。部署时结合 SPIFFE/SPIRE 等身份框架，为每个工作负载签发身份证书并自动轮换。

mTLS 提供"双向身份认证+加密"的信任基础，是服务网格与零信任的核心。零信任强调"每个请求都验证"，mTLS 使工作负载身份可验证、可审计。

• SCIM 的标准化身份模型
• 跨域同步的用户/组生命周期
• 与 IdP 的集成

SCIM 是跨域身份管理的标准化协议，用 RESTful API 与 JSON 定义用户、组、企业等实体的标准结构与增删改查、同步操作。工程价值在于：统一身份数据模型，让 IDaaS（如 Okta、Azure AD）与企业应用（SaaS、HR 系统）之间能标准化地同步用户生命周期（创建、更新、删除、停用），避免每个应用自定义集成。SCIM 提供 /Users、/Groups 端点与 schema 校验，支持批量操作与过滤，配合 OAuth/Bearer 认证，实现身份跨系统的一致性与自动化（如入职自动开通、离职自动停用）。

SCIM 解决"身份数据跨系统同步"的规范化问题，是身份治理与自动化（IT 系统）的基础。它定义"如何同步谁、同步什么"，减少手工与异构集成成本。

• JWS 的签名结构
• JWE 的加密结构
• JWK 的密钥表示

JWS 是 JSON 数据的签名格式，由 header（算法、kid）、payload 与 signature 组成，用于保证数据完整性与可验证性（如 JWT 的签名部分）。JWE 是 JSON 数据的加密格式，用密钥加密内容，提供机密性（如加密 JWT 用于敏感数据）。JWK 是 JSON 格式的密钥表示（如 RSA、EC 公钥/私钥的 JSON 描述），用于在系统间交换密钥。三者共同构成 JOSE（JSON Object Signing and Encryption）框架：JWS 签名、JWE 加密、JWK 表示密钥，是 JWT、OIDC 等现代身份协议的基础组件。

JOSE 把"签名、加密、密钥表示"标准化为 JSON。JWS 保证真实性，JWE 保证机密性，JWK 提供密钥互操作，三者可组合使用满足不同安全需求。

• 短生命周期 access token 与刷新 token 的分离
• 减少被盗 access token 的窗口
• 刷新 token 的存储与轮换

"短 token + 刷新 token"模式将 JWT 分为：短期 access token（如 15 分钟，用于访问受保护资源，附带在请求头）和长期 refresh token（如 7 天，仅用于换取新 access token，不直接访问资源）。这样即使 access token 被盗，其有效窗口短、影响小；refresh token 保存在客户端安全存储（如 HttpOnly Cookie、安全存储区），且通常与 client 绑定、支持轮换（每次使用刷新后轮换 refresh token）。该模式兼顾安全（短 access token 降低暴露）与体验（无需频繁重新登录），是现代 OAuth/OIDC 的标准做法。

核心是"最小暴露窗口"：access token 短命，被盗危害有限；refresh token 长命但只用做换 token，且可撤销、可轮换。二者分离实现安全与体验的平衡。

• 各算法的对称/非对称特性
• 密钥管理与性能
• 安全选型

alg 声明指定 JWT 的签名算法。HS256 是 HMAC-SHA256，对称密钥，签名与验证用同一密钥，适合单方签发验证（如服务端内部），需密钥保密。RS256 是 RSA-SHA256，非对称，公钥可公开验证，适合多方验证（如 OIDC 的 ID Token 由 IdP 签发、客户端用公钥验证）。ES256 是 ECDSA P-256，非对称，密钥更小、性能好，是 OIDC 常用。EdDSA 是 Ed25519 签名，非对称、确定性、抗侧信道，现代新系统推荐。选型：多方验证用非对称（RS256/ES256/EdDSA），单方用 HS256；不允许使用 alg=none（无签名）。

对称 vs 非对称是关键：HS256 密钥共享，泄露风险高；非对称算法公钥可公开。EdDSA 是当前最安全的现代选择。必须校验 alg 以防御算法混淆。

• 三段的结构与内容
• Base64url 编码
• 签名的作用

JWT 由三段 Base64url 编码的 JSON 组成，用点号分隔：header、payload、signature。header 包含算法（alg）与类型（typ）；payload 是声明（claims），如 iss、sub、aud、exp、iat、jti 等；signature 是对 header 与 payload 的签名（用 header 指定的算法对该编码串签名）。signature 保证 header 与 payload 未被篡改，且可验证签发者。三段构成一个自包含的、可验证的令牌。JWT 只做签名（JWS）或加密（JWE），payload 本身是明文 Base64url，因此不包含敏感机密（除非用 JWE 加密）。

三段式是 JWT 的核心结构。signature 是安全关键，payload 可被读取（Base64 解码），所以不能放敏感信息；header 的 alg 需校验以防算法混淆。

• PKCE 强制要求
• Implicit 流程的弃用
• Redirect URI 的严格校验

OAuth 2.1 整合了 OAuth 2.0 多年实践的安全改进：强制所有授权码流程使用 PKCE（即使机密客户端），防止授权码拦截；弃用 Implicit 流程（不再支持返回 access token 的隐式授权），统一使用授权码+PKCE；严格校验 Redirect URI（精确匹配、预先注册、禁止通配符），防止开放重定向与授权码劫持；同时要求 refresh token 支持轮换、限制其用途。OAuth 2.1 是"最佳实践"的整合，提升整体安全性并简化规范。

OAuth 2.1 的核心是"安全护栏"：PKCE 堵住授权码拦截、弃用 Implicit 消除 URL 泄露 token、严格 Redirect URI 防重定向劫持。这些是 OAuth 2.0 的安全性增强。

• ID Token 的身份声明
• UserInfo 端点
• Discovery 元数据

OIDC 在 OAuth 2.0 之上提供身份层。ID Token 是 JWT，包含用户身份声明（sub、iss、aud、exp、nonce 等），由 IdP 签名，客户端验证以确认用户身份与认证状态。UserInfo 端点返回用户信息（如姓名、邮箱、头像），客户端用 access token 查询。Discovery（OpenID Discovery）通过 /.well-known/openid-configuration 返回元数据（授权端点、token 端点、JWKS 端点、支持的算法等），客户端据此自动配置与发现。三者配合：ID Token 认证身份、UserInfo 获取资料、Discovery 自动发现端点。

OIDC 把"认证"（谁）与"授权"（能访问什么）结合。ID Token 证明身份，UserInfo 提供资料，Discovery 实现客户端自动配置，是现代化 OIDC 登录的标准。

• code_verifier 的随机性
• code_challenge 的变换
• 防授权码拦截

PKCE 用于授权码流程，防止授权码被拦截或恶意应用窃取。流程：客户端生成随机 code_verifier（高熵字符串），计算 code_challenge（通常为 code_verifier 的 SHA-256 哈希），在授权请求中发送 code_challenge 与 S256 方法；授权服务器回调时，客户端用 code_verifier 换取 token，服务器验证 code_verifier 的哈希是否与 code_challenge 一致。只有发起授权请求的客户端（持有 code_verifier）才能换取 token，即使授权码被窃取，攻击者没有 code_verifier 也无法换取 token，从而防授权码拦截。

PKCE 的本质是"证明持有授权请求的发起者"：code_verifier 是客户端才知道的秘密，code_challenge 是它的承诺。授权码与 code_verifier 绑定，拦截者无法兑换。OAuth 2.1 已强制要求。

• synced passkey 的云同步与多设备
• device-bound passkey 的硬件绑定
• 安全与可用性权衡

Passkeys 分两类：synced（设备同步）与 device-bound（设备绑定）。synced passkey 把私钥同步到云账户（如 iCloud Keychain、Google Password Manager），可在同一生态多设备间无缝使用，可用性好、可恢复，但私钥同步到云端，安全性依赖云账户安全（如 MFA）。device-bound passkey 把私钥绑定在单一硬件（如 YubiKey、安全芯片），不可同步、跨设备需重新注册，安全性更高（私钥不离硬件），但可用性差、丢失难以恢复。工程取舍：synced 兼顾多设备与易用，device-bound 提供更高安全，常用于高风险场景（金融、管理员）。

核心是"私钥在哪里"：synced 私钥在云端/多设备，device-bound 私钥在单一硬件。synced 牺牲一定防托管以换取可用性，device-bound 以可用性换取更强防泄露。两者都基于 WebAuthn。

• 各种 authenticator 的形态
• 平台 vs 漫游 authenticator
• 与 WebAuthn 的集成

WebAuthn 的 authenticator 是生成凭证并执行认证签名（私钥不离开）的硬件/平台组件。YubiKey 是漫游（cross-platform）authenticator，通过 USB/NFC 认证，私钥在硬件中，支持多设备。Touch ID、Windows Hello 是平台 authenticator，集成在设备（手机/电脑）的 TPM/安全芯片中，用生物识别解锁，私钥在设备内。Passkeys 是基于 WebAuthn 的凭证，可以是平台（synced）或漫游（device-bound）形式。它们都遵循"私钥不离开 authenticator、用 challenge 签名"的模型，只对外暴露公钥与断言签名。

authenticator 分为平台（内置，如 Touch ID/Windows Hello）与漫游（外接，如 YubiKey）。它们统一用 WebAuthn 协议暴露，服务端只存公钥，私钥在 authenticator 内，天然免疫口令泄露与钓鱼。

• 黑名单撤销
• 刷新 token 撤销
• 密钥轮换

JWT 是无状态的，服务器无法在签发后主动令其失效，撤销需额外机制。黑名单（blacklist）：把需撤销的 jti 加入服务端黑名单（带过期时间），验证时若 jti 在黑名单则拒绝。刷新 token 撤销：回收与之对应的 refresh token，使其无法再换取新 access token，从而实现间接撤销。密钥轮换：更换签名密钥（JWKS 中的新 key），使旧密钥签发的 token 失效（但需留容差窗口处理在途 token）。工程上常用"短 access token + 黑名单 jti + 可撤销 refresh token"组合，并支持按需强制下线。

JWT 无状态的优势也是撤销的难点。黑名单引入状态、刷新 token 提供回收入口、密钥轮换提供全局失效。按安全等级选择：普通场景用短 token+刷新，高风险场景用黑名单。

• refresh token 轮换
• 复用检测与 family
• 安全性提升

Refresh token rotation 指每次使用 refresh token 换取新 access token 时，同时签发新的 refresh token 并作废旧 refresh token，使旧 refresh token 失效。这样若旧的 refresh token 被盗，攻击者无法二次使用（已被轮换作废）。family 指一组由同一 refresh token 派生出的 refresh token 链；当检测到某个 refresh token 被复用（如被轮换已作废的 token 再次使用），则判定该 family 被泄露，撤销整个 family 的所有 refresh token，强制重新登录。rotation + family 检测显著提升 token 安全性，能抵御 refresh token 窃取与重放。

rotation 让 refresh token 一次性使用，family 检测协调整个派生链。这是 OAuth 2.1/BFF 的最佳实践，配合失窃检测能快速收拢泄露影响。

• jti 的唯一标识
• 防重放机制
• 与黑名单结合

jti（JWT ID）是 JWT 的声明，用于唯一标识一条 token。服务端可利用 jti 进行防重放：记录已使用的 jti（在一段时间内），若收到重复 jti 的 token 则判定为重放而拒绝。同时 jti 可用于构建撤销黑名单（把需撤销的 jti 列入黑名单）。jti 需由签发方生成、保证唯一且不可预测，配合 jti 的已用记录实现"每 token 一次性"或防重放检测。注意：jti 本身不防重放，必须由服务端维护"已见 jti"的有状态记录才能生效。

jti 是"标识"而非"安全机制"，防重放依赖服务端对 jti 的簿记。它与 exp/iat 结合，可精确跟踪每条 token 的签发、使用与撤销状态。

• attestation 证明凭证来源
• 各类型（basic/self/attca/anonca）的信任
• 服务端验证策略

WebAuthn attestation 是注册时 authenticator 对"凭证由可信硬件生成"的证明，包含 attestation 类型与数据。类型包括：basic（用设备证书）、self（自证）、attca（CA 证书）、anonca（匿名 CA）、none（不提供 attestation）。服务端验证 attestation 时，校验其证书链是否到可信根（厂商或 CA），决定是否信任该 authenticator 的声明。现实中很多平台 authenticator 返回 none 或 self（因隐私），服务端常以"忽略 attestation、信任 possess 断言"为主，仅在需要绑定特定硬件（如企业设备）时严格校验 attestation 类型。

attestation 验证服务端"凭证来自可信设备"的信任决策。basic/attca 有明确信任链，self/anonca 信任度低但隐私好。工程上按安全与隐私需求选择是否严格校验。

• synced 与 device-bound 的会话边界
• 云同步与硬件绑定的差异
• 跨厂商兼容

工程边界体现在"凭证的存储与可信根"：synced passkey（iCloud Keychain、Google Password Manager）把私钥同步到云账户，跨设备可用、可恢复，可信根是"云账户 + 设备解锁（生物识别）"，因此安全性依赖云账户的 MFA 与设备安全；device-bound passkey 把私钥绑在单一硬件（安全芯片/TPM），可信根是"该硬件"，不可云端同步、跨设备需重新注册。工程上，synced 适合作主认证（易用、多设备），device-bound 适合作高安全辅助（如特权操作、金融），且两者可共存（同一平台账户可同时有 synced 与 device-bound 凭证）。跨厂商兼容依赖 WebAuthn 标准与平台厂商的同步协议。

边界是"私钥可迁移性"与"安全锚点"：synced 锚定云账户+设备解锁，device-bound 锚定单硬件。基于此决定各自适用的安全场景与注册策略。