4、用户身份认证：OAuth2.0与JWT在寻源系统中的应用、SSO集成方案
4.1 认证体系在寻源系统中的定位
智能寻源系统涉及供应商数据、价格策略、合同条款等敏感信息，身份认证是安全架构的第一道防线。本章聚焦OAuth2.0授权框架与JWT令牌在寻源场景中的落地实践，以及如何通过SSO单点登录实现多系统间的无缝认证。
核心目标：确保每一次API调用、每一次页面跳转都携带可验证、不可篡改的身份凭证，同时支持跨系统、跨组织的权限传递。
4.2 OAuth2.0在寻源系统中的应用模式
4.2.1 授权码模式（Authorization Code）
寻源系统通常作为资源服务器（Resource Server）运行，前端应用或第三方集成工具通过授权码模式获取访问令牌。流程如下：
- 用户代理（浏览器/移动端）请求授权端点，携带 client_id 与 redirect_uri。
- 授权服务器验证用户身份后，返回授权码（code）到回调地址。
- 客户端应用使用授权码 + client_secret 向令牌端点换取 access_。
- 资源服务器（寻源API）验证 access_ 后返回受保护资源。
4.2.2 客户端凭证模式（Client Credentials）
适用于服务间通信，例如寻源算法引擎调用供应商数据库时，使用该模式直接获取令牌，无需用户交互。
| 模式 | 适用场景 | 安全等级 | 令牌有效期建议 |
|---|---|---|---|
| 授权码模式 | 前端用户登录、第三方集成 | 高（支持PKCE） | 15-30分钟 |
| 客户端凭证模式 | 后端服务、定时任务 | 中（依赖密钥管理） | 1-24小时 |
| 隐式模式（已弃用） | 不推荐在寻源系统中使用 | 低 | — |
安全提醒：寻源系统涉及采购价格、供应商评级等敏感数据，禁止使用隐式模式。授权码模式必须启用PKCE（Proof Key for Code Exchange）防止授权码拦截攻击。
4.3 JWT令牌结构与验证机制
4.3.1 JWT三段式结构
JWT（JSON Web ）由Header、Payload、Signature三部分组成，以Base64URL编码后通过点号（.）连接。在寻源系统中，Payload通常包含以下自定义声明：
{
"sub": "user_12345",
"iss": "sourcing-auth-server",
"aud": "sourcing-api",
"exp": 1718000000,
"iat": 1717996400,
"roles": ["sourcing_manager", "supplier_viewer"],
"permissions": {
"category:strategy:read": true,
"algorithm:config:write": false,
"supplier:score:read": true
},
"org_id": "org_6789",
"session_id": "sess_abc123"
}4.3.2 令牌验证流程
- 签名验证：使用RS256或HS256算法，确保令牌未被篡改。
- 过期检查：比对exp字段与当前服务器时间，拒绝过期令牌。
- 权限校验：从permissions字段提取细粒度权限，匹配当前请求的资源与操作。
- 吊销检查：查询Redis黑名单或数据库，确认令牌未被提前吊销。
最佳实践：JWT的Payload中不要存放密码、密钥等敏感信息。签名使用非对称算法（RS256），便于多个微服务独立验证而不共享密钥。
4.4 SSO单点登录集成方案
4.4.1 基于OAuth2.0 + OIDC的SSO架构
寻源系统通常与ERP、SRM、OA等系统共存，SSO方案让用户一次登录即可访问所有授权系统。推荐使用OpenID Connect（OIDC）在OAuth2.0之上增加身份层。
4.4.2 SSO集成关键步骤
| 步骤 | 操作 | 涉及组件 | 异常处理 |
|---|---|---|---|
| 1 | 用户访问寻源系统未登录页面 | 前端 → 寻源网关 | 检测无令牌，302重定向至SSO登录页 |
| 2 | SSO登录页认证（用户名密码/扫码/AD） | 授权服务器 | 认证失败返回错误码，记录审计日志 |
| 3 | 授权服务器返回授权码 | 授权服务器 → 寻源回调 | 授权码过期（10秒内必须使用） |
| 4 | 寻源后端用授权码换取令牌 | 寻源后端 → 授权服务器 | client_secret错误返回401 |
| 5 | 寻源系统解析ID ，建立本地会话 | 寻源后端 → Redis会话存储 | 签名验证失败拒绝登录 |
| 6 | 用户访问ERP/SRM，携带Access | 前端 → 各系统网关 | 令牌过期触发刷新流程 |
4.5 异常调试与安全审计
4.5.1 常见认证异常及排查
- 401 Unauthorized：令牌缺失、过期或签名不匹配。检查JWT的exp、iss、aud字段。
- 403 Forbidden：令牌有效但权限不足。检查permissions声明是否包含所需操作。
- 302重定向循环：SSO回调地址配置错误或cookie未正确传递。检查redirect_uri白名单。
- 令牌刷新失败：refresh_过期或已被吊销。建议refresh_有效期不超过7天。
调试工具推荐：使用jwt.io在线解析JWT的Payload与签名；在开发环境开启OAuth2.0调试端点（/oauth2/authorize?debug=true）查看完整请求链路。
4.5.2 安全审计要点
| 审计项 | 检查内容 | 频率 |
|---|---|---|
| 令牌签发日志 | 记录每次令牌签发的用户、时间、client_id、IP | 实时 |
| 令牌吊销记录 | 记录手动吊销、密码变更导致的令牌失效 | 实时 |
| 异常认证尝试 | 连续5次失败锁定账号，记录攻击来源 | 每日汇总 |
| 密钥轮换记录 | RS256私钥定期轮换，记录轮换时间与版本 | 每季度 |
4.6 本章小结
OAuth2.0与JWT为寻源系统提供了标准化、可扩展的身份认证底座。通过授权码模式保障前端安全，客户端凭证模式支撑服务间通信，再结合SSO实现多系统统一认证，能够有效降低凭证泄露风险、提升用户体验。在实际部署中，务必关注令牌有效期、签名算法强度、吊销机制与审计日志的完整性，形成闭环的安全防护体系。