2. 认证服务边界定义
认证服务边界是 IAM 平台架构设计的首要决策点。边界定义不清晰，会导致职责混乱、安全漏洞和集成困难。本节从职责范围、外部系统交互和核心接口三个维度，精确划定认证服务的边界。
2.1 用户身份验证的职责范围
认证服务的核心职责是验证用户声称的身份是否真实，并生成可信任的身份凭证。其职责范围必须严格限定，避免与授权、用户管理等模块职责重叠。
| 职责域 | 包含内容 | 不包含内容 |
|---|---|---|
| 身份验证 | 密码校验、多因素认证、生物识别、SSO 断言验证 | 用户注册、密码修改、账户锁定/解锁 |
| 凭证管理 | 令牌签发、令牌刷新、令牌撤销、会话管理 | 权限分配、角色管理、资源访问策略 |
| 身份断言 | 生成 JWT/SAML/OIDC 身份令牌、传递用户属性 | 权限决策、资源级访问控制 |
| 安全审计 | 认证事件记录、失败尝试追踪、异常检测 | 授权日志、资源操作审计 |
架构原则：认证服务只回答"你是谁"，不回答"你能做什么"。授权决策必须由独立的授权服务完成，避免认证服务膨胀为"全能网关"。
2.2 与外部系统的交互边界
认证服务不是孤岛，它需要与多个外部系统协作。清晰的交互边界能降低耦合度，提升安全性和可替换性。
核心交互关系：
- 用户 → 认证服务：提交身份凭证（用户名/密码、MFA 码、生物特征）
- 认证服务 → 身份存储：查询用户凭证哈希、账户状态、MFA 配置
- 认证服务 → 令牌存储：持久化已签发令牌、维护黑名单
- 认证服务 → 授权服务：传递已验证的身份断言（用户 ID、属性、会话上下文）
- 认证服务 → 审计日志：异步写入认证事件流
边界陷阱：认证服务不应直接访问授权策略数据库，也不应承担用户注册、密码重置等用户管理职责。这些操作应通过用户管理服务处理，认证服务仅接收最终结果。
2.3 认证服务的核心接口定义
认证服务对外暴露的接口必须遵循最小化原则，每个接口承担单一职责。以下是标准化的核心接口定义：
| 接口名称 | 请求方法 | 端点路径 | 核心参数 | 返回结果 |
|---|---|---|---|---|
| 登录认证 | POST | /auth/login |
username, password, mfa_code | access_token, refresh_token, expires_in |
| 令牌刷新 | POST | /auth/refresh |
refresh_token | access_token, refresh_token, expires_in |
| 令牌验证 | POST | /auth/verify |
access_token | user_id, attributes, valid |
| 令牌撤销 | POST | /auth/revoke |
access_token / refresh_token | success, revoked_at |
| 登出 | POST | /auth/logout |
access_token | success |
| MFA 挑战 | POST | /auth/mfa/challenge |
user_id, mfa_type | challenge_id, expires_in |
| MFA 验证 | POST | /auth/mfa/verify |
challenge_id, code | verified, session_token |
2.4 接口调用示例
以下是一个标准的登录认证请求与响应示例，展示了认证服务的实际交互模式：
// 请求：用户登录
POST /auth/login
Content-Type: application/json
{
"username": "zhangsan@example.com",
"password": "P@ssw0rd!2024",
"mfa_code": "123456"
}
// 响应：认证成功
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
"refresh_token": "dGhpcyBpcyBhIHJlZnJlc2ggdG9rZW4...",
"expires_in": 3600,
"token_type": "Bearer",
"user_id": "u-2024-001",
"session_id": "sess-abc123"
}
// 响应：认证失败
HTTP/1.1 401 Unauthorized
Content-Type: application/json
{
"error": "invalid_credentials",
"error_description": "用户名或密码错误",
"remaining_attempts": 3
}
接口设计要点：
- 无状态优先：认证服务优先使用 JWT 等自包含令牌，减少服务端会话存储依赖
- 统一错误格式：所有认证接口返回一致的错误结构，包含错误码、描述和可操作提示
- 速率限制：登录接口必须实施基于 IP 和用户名的速率限制，防止暴力破解
- 令牌轮换：刷新令牌时同时返回新的 access_token 和 refresh_token，旧令牌立即失效
2.5 边界定义检查清单
在完成认证服务边界定义后，使用以下清单进行自检，确保边界清晰且无职责泄漏：
- 职责单一性：认证服务是否只处理"验证身份"和"签发凭证"？是否混入了授权决策？
- 数据隔离：认证服务是否直接访问了授权策略表或用户个人信息表？
- 接口最小化：对外暴露的接口是否都是认证所必需的？是否有可合并或移除的接口？
- 依赖方向：认证服务是否依赖了授权服务？正确的依赖方向是认证服务→授权服务传递断言。
- 令牌生命周期：令牌的签发、验证、刷新、撤销是否都在认证服务内部闭环？
- 安全边界：认证服务是否在独立的网络域或进程空间中运行？是否与外部系统有防火墙隔离？
最佳实践：在微服务架构中，建议将认证服务部署为独立的进程或容器，与授权服务、用户管理服务完全解耦。认证服务只通过 gRPC 或 REST API 与外部系统通信，不共享数据库实例。