1. 服务边界拆分概述
1.1 IAM平台在企业架构中的定位
在典型的企业数字化架构中，IAM（Identity and Access Management）平台处于基础设施层与业务应用层之间的核心枢纽位置。它不直接产生业务价值，但为所有业务系统提供统一的身份认证、权限管理和审计能力，是保障企业信息安全的“第一道防线”。
核心定位：IAM平台是企业数字身份的“单一可信源”（Single Source of Truth），负责解决“你是谁、你能做什么、你做了什么”三个根本问题。
从分层架构视角看，IAM平台通常位于以下位置：
| 架构层次 | 典型组件 | 与IAM的关系 |
|---|---|---|
| 业务应用层 | CRM、ERP、OA、HRM | 消费IAM提供的认证与授权结果 |
| IAM平台层 | 认证中心、授权中心、用户目录 | 提供统一身份与权限服务 |
| 基础设施层 | LDAP、AD、数据库、网络 | 提供用户数据存储与传输支撑 |
1.2 认证与授权的核心职责
认证（Authentication）与授权（Authorization）是IAM平台的两大核心职责，二者在概念上紧密关联，但在职责边界上必须清晰分离。
| 维度 | 认证（Authentication） | 授权（Authorization） |
|---|---|---|
| 核心问题 | 你是谁？ | 你能做什么？ |
| 输入 | 凭证（密码、生物特征、证书） | 身份标识 + 资源请求 |
| 输出 | 身份令牌（Token / Session） | 权限决策（Allow / Deny） |
| 典型协议 | OAuth2.0、OIDC、SAML、LDAP | RBAC、ABAC、PBAC、XACML |
| 失败影响 | 无法登录系统 | 越权操作或数据泄露 |
设计原则：认证只负责“验证身份真实性”，不决定“能访问哪些资源”；授权只负责“基于身份做权限判断”，不关心“身份如何验证”。二者职责分离是服务边界拆分的第一原则。
1.3 服务边界拆分的必要性
在早期单体IAM系统中，认证与授权逻辑往往耦合在同一个代码库中。随着企业规模扩大和业务复杂度提升，这种耦合带来了以下问题：
- 扩展性瓶颈：认证请求（高频、短连接）与授权请求（低频、策略复杂）混合处理，难以独立扩缩容。
- 安全风险扩散：认证模块的漏洞可能直接暴露授权策略引擎，攻击面扩大。
- 迭代效率低下：认证协议升级（如从SAML迁移到OIDC）需要连带修改授权逻辑，发布周期长。
- 策略管理混乱：授权规则散落在认证流程中，难以统一治理和审计。
服务边界拆分的目标是将认证与授权拆分为独立的微服务模块，各自拥有独立的存储、API和部署单元。拆分后的典型架构如下：
常见误区：拆分不等于完全割裂。认证服务颁发的令牌中必须包含授权服务所需的身份信息（如用户ID、角色列表），二者通过标准化的令牌格式（如JWT）进行数据交换。拆分的是服务边界，而非数据关联。
1.4 拆分后的交互流程
服务边界拆分后，一次完整的用户请求需要经过以下标准流程：
- 用户登录：客户端向认证服务提交凭证，认证服务验证通过后颁发JWT令牌。
- 请求资源：客户端携带JWT令牌向API网关发起资源访问请求。
- 令牌校验：API网关或授权服务校验JWT的签名和有效期，确认身份有效。
- 权限决策：授权服务根据令牌中的身份信息、请求的资源路径和操作类型，匹配策略引擎做出Allow/Deny决策。
- 返回结果：授权通过则转发请求到后端业务服务，否则返回403 Forbidden。
关键设计要点：认证服务与授权服务之间不直接通信，而是通过JWT令牌作为“信使”。令牌中携带的claims（声明）应包含授权决策所需的最小信息集，避免过度暴露敏感数据。