基于会话的信任验证降级机制设计与实现
目标
在保障安全的前提下，减少用户重复验证的打扰，提升用户体验。
- 在一个用户会话上下文中，已通过高级别验证后，可以跳过或自动通过低级别验证。
- 降低重复验证导致的用户流失，提高交互效率。
前提是保证整体风控策略的安全性和可解释性。
核心思路与流程梳理
信任传递+"会话"上下文管理
这里的"会话"不仅仅指真实会话，还可以是订单、动作或者子会话等。
1. 业务应用发送请求到风控系统进行决策
附带大量信息：事件时间、IP、经纬度、设备信息等。
2. 风控系统决策
风控系统根据规则引擎进行决策，判断是否可以进行降级处理。
3. 可降级时，判断是否降级
可以根据具体需求，增加额外的安全策略，如：
- 同一IP
- 设备ID
- 地理位置等因素
4. 可降级，则输出降级方案
存储与校验
以Redis为例，使用复合键+过期时间（TTL）来存储验证记录。
Key: vrf:u_{userId}:s_{sessionId}
Value: JSON格式的验证记录
TTL: 15分钟（可配置）
降级检查伪代码：
String key = "vrf:" + userId + ":" + sessionId;
VerificationResult result = redis.get(key);
if (result != null && result.level >= requiredLevel && result.expiresAt > now) {
return AllowVerificationSkip();
}
return RequireVerification();
风控轨迹审计与可视化
每次风控降级都需要保留完整的记录，便于后续数据分析和审查。
可视化方向是将同一事件的整个生命周期（事中、验证结果、事后结果）整合展示。
注意事项
| 类别 | 注意点 |
|---|---|
| 安全性 | - 严格定义验证等级，防止绕过 - 高风险行为（如提现到新账户、修改收货人等）不适用降级 - 检测到会话被篡改或重放攻击，立即终止信任关系并重新验证 - 验证机制应包含多维度信息（用户、设备、订单等） |
| 会话隔离性 | - 确保不同设备（app/web/xcx）之间的会话隔离 |
| 风控规则兼容性 | - 验证等级定义与风险引擎解耦 - 便于策略灵活调整 |
| 数据存储 | - 验证状态建议短期存储在Redis，长期存储在数据库 - 支持多维度（用户、设备、订单）和多租户应用 |
| 时效性 | - 验证状态应设置有效期，如人脸识别通过后仅在15分钟内有效 |
| 审计性 | - 所有验证跳过的情况都需要完整的风控轨迹日志 |
