1. 项目概述从单体授权到分离架构的演进之路在构建现代应用安全体系时授权Authorization是绕不开的核心议题。过去我们常常将认证Authentication和授权逻辑与业务代码紧密耦合或者使用一个庞大的、一体化的授权服务器Authorization Server, AS来包办一切。这种模式在微服务、多租户、分布式系统成为主流的今天显得越来越笨重和脆弱。一个服务的认证逻辑变更可能引发整个授权体系的连锁反应一个租户的权限模型调整可能需要全站停机更新。这正是“OAuth 2.1 与授权架构 —— AS/RS 分离的正确姿势”这个标题背后所指向的深层痛点如何设计一个既能满足复杂业务需求又能保持高可用、易扩展、好维护的授权体系。OAuth 2.1 作为 OAuth 2.0 的安全增强版不仅修复了已知的安全漏洞其设计哲学也更加强调模块化和清晰的职责边界。其中将授权服务器AS与资源服务器RS进行彻底分离正是实现这一哲学的关键技术路径。这不仅仅是部署上的分离更是逻辑、数据、乃至团队职责的分离。AS 专注于“颁发令牌”这一件事验证用户身份、确认授权范围、生成并签名令牌。而 RS 则专注于“校验令牌并授权访问资源”它无需理解复杂的认证流程只需信任来自 AS 的令牌并依据令牌中的声明Claims做出访问控制决策。这种分离带来的好处是实实在在的。想象一下你的用户认证系统需要从数据库迁移到第三方身份提供商如企业微信登录你只需要在 AS 侧进行适配所有依赖该 AS 令牌的资源服务器都无需任何改动。再比如你需要为不同的业务线如电商、内容、金融设计截然不同的权限模型你可以部署多个轻量级的 RS它们共享同一个权威的 AS各自实现复杂的业务权限逻辑而 AS 保持稳定和纯粹。这种架构的弹性是单体授权系统难以企及的。接下来我将结合自己多年在身份与访问管理IAM领域的实战经验为你彻底拆解 AS/RS 分离架构的设计思路、核心组件、实操步骤以及那些只有踩过坑才知道的注意事项。无论你是在规划一个新系统的授权体系还是正在为遗留系统的授权混乱而头疼这篇文章都将提供一套可直接落地的参考方案。2. 架构核心深入理解 AS 与 RS 的职责边界要实现正确的分离首先必须像宪法界定三权一样清晰无误地划定 AS 和 RS 的职权范围。任何模糊地带都是未来系统腐化和维护噩梦的源头。2.1 授权服务器AS的单一职责令牌的颁发者与验证者AS 的核心使命是作为系统中受信任的第三方负责颁发代表用户授权意愿的访问令牌Access Token。它的所有工作都围绕令牌的生命周期展开。1. 端点Endpoint暴露与管理一个标准的 AS 至少需要提供以下端点/authorize授权端点处理用户的交互式登录和授权同意。这是 OAuth 流程的起点通常涉及重定向和会话管理。/token令牌端点用于通过授权码Authorization Code、客户端凭证Client Credentials等授权类型交换访问令牌和刷新令牌。这是 AS 最核心的接口。/jwks提供 JSON Web Key Set公开用于验证令牌签名如 RS256 算法的公钥。这是 RS 能够信任 AS 所颁发令牌的技术基础。/userinfo可选但推荐用户信息端点RS 或其他客户端可以使用有效的访问令牌从此端点获取用户的标准身份信息如 sub, name, email。这有助于 RS 获取基础身份数据而无需在令牌中携带过多隐私信息。/introspect可选令牌内省端点允许资源服务器提交一个令牌由 AS 返回该令牌的当前状态是否有效、过期时间、授权范围等。这是一种集中式的令牌验证方式适用于对实时吊销要求极高的场景。2. 客户端Client注册与凭证管理AS 需要维护所有注册客户端的清单包括客户端ID、密钥、重定向URI、授权类型、授权范围等。客户端凭证的安全存储如使用加盐哈希和传输必须使用TLS是 AS 安全的第一道防线。3. 用户认证与同意AS 集成了实际的用户认证手段可能是用户名密码、社交登录、短信验证码等。在授权码流程中AS 负责引导用户完成认证并清晰地展示请求的权限范围Scopes获取用户的明确同意Consent。这个“同意记录”是审计的关键依据。4. 令牌的生成与签名AS 根据认证和授权结果生成结构化的令牌。目前 JWTJSON Web Token是事实标准。AS 使用自己的私钥对 JWT 进行签名例如使用 RS256 算法确保令牌的完整性和来源可信。令牌的 payload 部分应包含必要的最小声明集如iss签发者即 AS 自己、sub用户标识、aud受众通常为 RS 的标识符、exp过期时间、scope授权范围。注意AS 绝对不应该包含任何业务逻辑或业务数据。它的世界里只有“用户”、“客户端”、“令牌”和“授权范围”。它不关心“订单”、“文章”或“财务报表”。一旦 AS 开始根据用户角色返回不同的业务字段分离就失败了。2.2 资源服务器RS的专注职责令牌的消费者与资源的守卫RS 的职责相对纯粹保护它管辖下的 API 或数据资源。它不关心用户是怎么登录的只关心“持票人”是否有权访问特定资源。1. 令牌的接收与验证RS 从收到的 HTTP 请求通常在Authorization: Bearer token头中提取访问令牌。随后它必须对令牌进行一系列严格的验证结构验证令牌是否是格式正确的 JWT签名验证使用从 AS 的/jwks端点获取的公钥验证签名确保令牌确实由可信的 AS 签发且未被篡改。标准声明验证iss签发者是否与信任的 AS 标识符匹配aud受众是否包含本 RS 的标识符这是防止令牌被滥用至非目标服务的关键检查。exp过期时间是否已过期nbf生效时间如果有是否已生效业务声明验证可选检查scope是否包含访问当前端点所需的权限范围例如read:orders。2. 访问控制决策令牌验证通过后RS 需要基于令牌中的信息主要是sub和scope以及请求的上下文如请求的URL路径、HTTP方法、请求的资源ID执行具体的授权逻辑。基于范围的授权Scope-Based这是最常用的一层。例如一个拥有write:articles范围的令牌可以调用POST /api/articles但不能调用GET /api/financial-reports后者可能需要read:reports范围。这通常在 API 网关或全局过滤器中实现。基于资源的授权Resource-Based这是更细粒度的控制。例如用户Asubuser_a可以GET /api/articles/123但用户B不能因为文章123的作者是用户A。这种逻辑强烈依赖于业务数据必须在 RS 的业务逻辑层内部实现。RS 需要根据sub去查询数据库判断用户与资源的关系。3. 与 AS 的协作可选对于某些高级场景RS 可能需要与 AS 进行额外交互令牌内省当使用不透明令牌非JWT或需要实时检查令牌吊销状态时RS 可以调用 AS 的/introspect端点。获取用户信息如果 JWT 中携带的信息不足RS 可以调用 AS 的/userinfo端点使用访问令牌获取更完整的用户档案。清晰的边界带来的直接好处就是独立部署与扩展。AS 作为安全核心访问模式相对稳定可以侧重于安全加固、高可用和审计。而各个 RS 可以根据其业务负载特性独立进行伸缩。电商订单服务RS在“双十一”期间可以扩容到100个实例而用户信息服务另一个RS可能只需要10个实例它们都向同一个 AS 集群验证令牌互不干扰。3. 技术选型与核心组件实战理论清晰后我们需要选择合适的工具来实现这套架构。市面上有成熟的开源解决方案也有商业产品对于大多数团队从开源方案开始是性价比最高的选择。3.1 授权服务器AS选型IdentityServer vs Keycloak这是最关键的决策点之一。两个主流开源方案是 .NET 系的IdentityServer和 Java 系的Keycloak。IdentityServer (Duende IdentityServer)定位一个高度可定制、库级别的 OAuth 2.1/OpenID Connect 框架。优点与 ASP.NET Core 生态无缝集成对于 .NET 技术栈团队来说开发体验极佳。代码级控制你可以深入到流程的每一个细节进行定制非常适合有复杂定制化需求的场景如特殊的授权流程、自定义令牌格式。文档清晰社区活跃。缺点需要自行实现用户界面登录页、同意页、用户存储通常是数据库和客户端配置存储。它提供了构建 AS 所需的所有“零件”但你需要自己“组装成车”。对于生产环境你需要考虑持久化、集群、缓存等一系列问题。Duende 版本在商业应用上有授权许可要求需要留意其商业政策。适合场景.NET 技术栈为主对授权流程有深度定制需求且团队有足够精力进行集成和运维的中大型项目。Keycloak定位一个开箱即用的完整身份认证与访问管理解决方案。优点开箱即用自带功能完善的管理控制台可以通过 UI 配置客户端、用户、角色、领域Realm。内置登录、注册、账户管理页面。功能全面不仅支持 OAuth 2.1/OIDC还支持 SAML自带社交登录Google, GitHub等适配器支持细粒度的基于角色的权限管理Role-Based Access Control。易于集成对客户端应用友好提供多种语言的适配器Adapter。作为 RS你通常只需要配置一个连接器即可。集群、持久化等生产级特性原生支持。缺点相对“重”定制化不如 IdentityServer 灵活。如果你需要的行为不在其预设范围内定制开发可能比较麻烦。默认配置可能较为复杂学习曲线前期较陡。适合场景需要快速搭建一个功能完整、生产可用的 AS技术栈多样Java, .NET, Node.js等且对开箱即用和统一管理有强烈需求的团队。我的实战建议如果你的团队技术栈混合或者希望快速上线、减少在身份认证基础组件上的开发投入Keycloak 通常是更优选择。它让你能更专注于业务 RS 的开发。而对于深度绑定 .NET、且授权逻辑极为特殊的场景IdentityServer 提供了无与伦比的灵活性。3.2 资源服务器RS实现以 ASP.NET Core 为例无论 AS 选型如何RS 的实现模式是通用的。在 ASP.NET Core 中我们可以利用其强大的认证/授权中间件体系。1. 核心依赖包dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer这个包提供了验证 JWT Bearer Token 的认证处理器。2. 服务配置Program.cs 或 Startup.cs// 从配置或环境变量获取 AS 的地址和 RS 自身的标识符 var authority Configuration[OAuth:Authority]; // 例如https://auth.yourdomain.com var audience Configuration[OAuth:Audience]; // 你的 RS 标识符必须与 AS 颁发令牌时的 aud 匹配 builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddJwtBearer(options { options.Authority authority; options.Audience audience; // 验证令牌的 aud 声明 options.TokenValidationParameters new TokenValidationParameters { ValidateIssuer true, // 验证签发者 ValidateAudience true, // 验证受众 ValidateLifetime true, // 验证有效期 ValidateIssuerSigningKey true, // 验证签名密钥 // 通常不需要指定 IssuerSigningKey框架会通过 Authority 自动发现 JWKS 端点获取公钥 }; // 可选对于内网或特定环境可能需要禁用 HTTPS 元数据请求生产环境绝不允许 // options.RequireHttpsMetadata false; // 可选设置令牌提取方式默认从 Authorization 头读取 Bearer Token // options.Events new JwtBearerEvents { ... }; }); builder.Services.AddAuthorization(); // 添加授权服务3. 中间件与端点保护 在请求管道中启用认证和授权中间件app.UseAuthentication(); app.UseAuthorization();然后在控制器或最小 API 端点中使用特性进行保护[ApiController] [Route(api/[controller])] [Authorize] // 要求请求必须携带有效令牌 public class OrdersController : ControllerBase { [HttpGet({id})] [RequiredScope(read:orders)] // 更细粒度要求令牌必须包含 read:orders 范围 public IActionResult GetOrder(int id) { // 可以通过 User.Identity.Name 或 User.FindFirst(ClaimTypes.NameIdentifier)?.Value 获取 sub var userId User.FindFirst(sub)?.Value; // 结合 userId 和 id 执行基于资源的授权逻辑例如检查订单是否属于该用户 // ... return Ok(order); } [HttpPost] [RequiredScope(write:orders)] public IActionResult CreateOrder([FromBody] Order order) { // ... return CreatedAtAction(nameof(GetOrder), new { id order.Id }, order); } }这里的[RequiredScope]特性需要自定义或使用类似Microsoft.Identity.Web库提供的特性。其原理就是在授权过滤器Authorization Filter中检查User.Claims中是否存在对应的scope声明。3.3 令牌格式与安全JWT 的细节魔鬼JWT 是 AS/RS 分离架构中信息传递的载体其设计和使用中的细节至关重要。1. 令牌内容设计Payload 一个设计良好的 JWT Payload 应该遵循“最小必要”原则。{ iss: https://auth.yourcompany.com, aud: [api.orders, api.users], // 受众可以是数组表明此令牌可用于多个RS exp: 1735689600, sub: user-123456, scope: read:orders write:orders openid profile, client_id: spa-client-app, auth_time: 1735686000 }避免放入敏感信息如密码、完整地址、支付信息等。JWT 默认只进行 Base64 编码而非加密除非使用 JWE。任何拿到令牌的人都可以解码看到 payload 内容。谨慎使用自定义声明只添加 RS 进行访问控制所必需的信息。例如可以添加tenant_id用于多租户隔离或role用于简单的角色判断但复杂授权建议基于scope和sub在 RS 内查询。aud声明的意义这是安全的关键。AS 在颁发令牌时必须根据客户端请求的 RS API 来正确设置aud。RS 在验证时必须严格检查aud是否包含自己。这能防止一个发给“订单服务”的令牌被意外或恶意用于访问“财务服务”。2. 签名算法选择HS256对称加密使用同一个密钥进行签名和验证。在 AS/RS 分离架构中绝对禁止使用因为你需要将密钥分发给所有 RS密钥泄露风险呈指数级增长且一个 RS 的密钥泄露会危及所有服务。RS256 / ES256非对称加密AS 使用私钥签名RS 使用公钥验证。公钥可以安全地通过 JWKS 端点公开。这是分离架构的唯一推荐选择。RS256 基于 RSAES256 基于椭圆曲线 ECDSA后者密钥更短、性能可能更好但兼容性略差RS256 是目前最通用的选择。3. 令牌生命周期与刷新访问令牌Access Token生命周期应较短建议 5-15 分钟。这限制了令牌泄露后造成的破坏时间窗口。刷新令牌Refresh Token生命周期较长如 7 天或更长。用于在访问令牌过期后获取新的访问令牌而无需用户重新登录。刷新令牌必须被 AS 安全地存储如数据库并与客户端和用户绑定且应具备吊销机制。4. 令牌存储与传输前端SPA、移动App访问令牌不建议存储在localStorage或sessionStorage中有 XSS 风险。推荐使用内存存储或使用带有HttpOnly、Secure、SameSite标记的 Cookie但需注意 CSRF 防护。刷新令牌绝对不可以暴露给前端应仅用于后端机密客户端。后端 RS 间调用当一个 RS如 API Gateway需要调用另一个 RS如订单服务时它应该使用客户端凭证流Client Credentials Flow获取一个代表服务本身而非用户的令牌或者将原始用户令牌JWT以“Bearer Token”形式传递给下游服务即 Token Propagation 模式。后者更常见但要求所有下游 RS 都信任同一个 AS。4. 完整部署与配置流程实录让我们以一个典型的微服务场景为例实战演练从零搭建一套 AS/RS 分离的授权体系。假设我们有一个电商系统包含用户服务、订单服务和商品服务。4.1 步骤一部署与配置授权服务器以 Keycloak 为例启动 Keycloak使用 Docker 是最快的方式。docker run -d \ --name keycloak \ -p 8080:8080 \ -e KEYCLOAK_ADMINadmin \ -e KEYCLOAK_ADMIN_PASSWORDyour_strong_password \ quay.io/keycloak/keycloak:latest start-dev生产环境需要配置数据库如 PostgreSQL、设置 HTTPS、配置集群等。登录管理控制台访问http://localhost:8080使用 admin/your_strong_password 登录。创建领域Realm领域是隔离租户和应用的顶级容器。点击左上角下拉框选择 “Create realm”命名为 “E-Commerce”。创建客户端Client在 “E-Commerce” 领域下进入 “Clients” - “Create client”。Client IDorder-service代表我们的订单资源服务器。Client Protocolopenid-connect。点击 “Save”。在客户端的设置页中配置关键项Access Type选择confidential表示这是一个后端服务能安全保存密钥。Valid Redirect URIs对于 RS通常不需要前端重定向可以留空或填写一个占位符。如果是 SPA 客户端则需精确配置其回调地址。Web Origins根据需要配置 CORS。保存后切换到 “Credentials” 标签页这里会自动生成Client Secret记录下来RS 配置时会用到。定义客户端作用域Client Scopes进入 “Client scopes”点击 “Create”。名称read:orders描述读取订单权限。协议openid-connect。同样创建write:orders、read:products等。这些作用域可以在颁发令牌时被请求和授予。将作用域关联到客户端回到order-service客户端的 “Client Scopes” 标签页。在 “Default Client Scopes” 中将read:orders和write:orders添加进去。这意味着当为该客户端颁发令牌时这些作用域可以作为默认值或可选值。配置 Mappers可选如果你需要在令牌中添加自定义声明可以在客户端的 “Mappers” 标签页创建。例如创建一个 “User Attribute” 类型的 Mapper将用户的department属性映射到令牌的department声明。获取 JWKS 端点地址AS 的公钥信息通过一个标准的发现端点提供。地址通常是http://localhost:8080/realms/e-commerce/protocol/openid-connect/certs。这个地址就是 RS 配置中Authority的基础 URLhttp://localhost:8080/realms/e-commerce加上标准路径。4.2 步骤二配置订单服务RS以验证 Keycloak 令牌在订单服务的 ASP.NET Core 项目中进行如下配置安装 NuGet 包如前所述安装Microsoft.AspNetCore.Authentication.JwtBearer。appsettings.json 配置{ OAuth: { Authority: http://localhost:8080/realms/e-commerce, Audience: order-service // 必须与 Keycloak 中创建的 Client ID 完全一致 } }服务注册与中间件配置代码与 3.2 节所示完全一致。框架会自动从{Authority}/.well-known/openid-configuration发现端点获取配置包括jwks_uri。测试令牌获取与访问使用 Postman 或 curl 向 Keycloak 的令牌端点发起请求模拟客户端获取令牌curl -X POST \ http://localhost:8080/realms/e-commerce/protocol/openid-connect/token \ -H Content-Type: application/x-www-form-urlencoded \ -d client_idorder-serviceclient_secretYOUR_CLIENT_SECRETgrant_typeclient_credentialsscoperead:orders这里使用了客户端凭证流适用于服务间调用。如果是用户登录应使用授权码流程。从响应中提取access_token。用这个令牌访问订单服务的受保护端点curl -X GET \ http://localhost:5000/api/orders \ -H Authorization: Bearer YOUR_ACCESS_TOKEN如果配置正确订单服务应该返回 200 OK 和订单数据如果没有令牌或令牌无效则返回 401 Unauthorized。4.3 步骤三实现基于资源的细粒度授权令牌验证通过只解决了“你是谁”认证和“你有什么通用权限”基于Scope的授权的问题。要判断“你能否操作这个特定资源”需要在业务逻辑中实现。在订单服务的GetOrder(int id)方法中[HttpGet({id})] [RequiredScope(read:orders)] public async TaskIActionResult GetOrder(int id) { // 1. 从已验证的令牌中获取用户标识 var userId User.FindFirst(sub)?.Value; if (string.IsNullOrEmpty(userId)) { return Forbid(); // 理论上不会发生因为 [Authorize] 已通过 } // 2. 从数据库查询订单 var order await _orderRepository.GetByIdAsync(id); if (order null) { return NotFound(); } // 3. 执行基于资源的授权逻辑 // 规则示例订单只能由其所属用户或管理员访问 bool isOwner order.UserId userId; // 假设我们从令牌或通过 UserInfo 端点获取了用户角色更佳实践是在RS内维护用户-角色映射 bool isAdmin User.IsInRole(admin); // 或者检查 role 声明 if (!isOwner !isAdmin) { // 用户无权访问此特定资源 return Forbid(); // 返回 403 Forbidden与 401 Unauthorized未认证区分开 } // 4. 授权通过返回资源 return Ok(order); }这种逻辑完全内聚在 RS 内部与 AS 无关。AS 只负责告诉 RS “来人是 user-123”而 RS 自己决定 user-123 能看到哪些订单。5. 生产环境进阶考量与避坑指南将分离架构投入生产会面临更多复杂性和挑战。以下是我从多次项目实践中总结的关键点。5.1 性能、缓存与高可用JWKS 端点缓存RS 每次验证 JWT 签名时都需要获取 AS 的公钥。频繁请求/jwks端点会给 AS 带来压力并增加 RS 的响应延迟。必须在 RS 端实现公钥缓存。Microsoft.AspNetCore.Authentication.JwtBearer库内置了缓存机制通过ConfigurationManager默认会缓存获取的配置信息。你需要关注缓存过期时间通常与 Keycloak 的密钥轮换周期相关确保在 AS 轮换签名密钥后RS 能及时更新缓存。AS 的高可用AS 是系统的单点故障源SPOF。必须对 AS 进行集群部署。对于 Keycloak这意味着配置共享的外部数据库如 PostgreSQL和负载均衡器。所有 AS 实例共享同一套客户端和用户配置。对于 IdentityServer需要确保配置数据存储如IClientStore,IResourceStore和操作数据存储如IPersistedGrantStore使用共享数据库并考虑分布式缓存如 Redis来共享签名密钥材料。RS 的无状态化得益于 JWT 的自包含性RS 本身可以设计为无状态的这非常利于水平扩展。授权决策所需的信息sub,scope都在令牌里业务授权所需的数据则来自独立的数据库或缓存。5.2 密钥管理、轮换与安全加固私钥安全AS 的签名私钥是其生命线。必须存储在安全的硬件模块HSM或至少是安全的密钥管理服务KMS中。在 Docker/ Kubernetes 环境中避免将私钥硬编码在镜像或环境变量中应使用 Secrets 管理工具。密钥轮换Key Rotation定期更换签名密钥是安全最佳实践。Keycloak 和 IdentityServer 都支持自动密钥轮换。关键在于平滑过渡。新密钥生成后旧密钥仍在 JWKS 中应在一段时间内继续有效以验证那些尚未过期的旧令牌。RS 的 JWKS 缓存机制需要能够自动发现新密钥。令牌吊销Token RevocationJWT 一旦签发在过期前无法单方面作废这是其最大缺点。对于需要立即吊销的场景如用户登出、管理员禁用账户有几种策略使用短寿命令牌将访问令牌有效期设为极短如5分钟依赖刷新令牌来维持会话。吊销时只需在 AS 端使刷新令牌失效即可。这是最常用、最简单的方案。令牌内省Token IntrospectionRS 每次收到令牌都向 AS 的/introspect端点查询状态。这提供了最强的实时性但代价是每次 API 调用都增加了一次网络请求严重牺牲性能和可用性仅适用于对安全有极端要求的内部管理接口。黑名单BlacklistAS 维护一个已吊销令牌IDJTI的黑名单并同步给所有 RS如通过 Redis Pub/Sub。RS 在验证令牌时额外检查黑名单。这增加了架构复杂性。我的建议是优先采用“短寿命访问令牌 可吊销的刷新令牌”组合在安全与复杂度之间取得最佳平衡。5.3 跨服务调用服务网格集成在微服务架构中一个用户请求可能涉及多个 RS 的链式调用。如何传递用户身份上下文模式一令牌传播Token Propagation网关或第一个 RS 将收到的原始 JWT 放在请求头中传递给下游服务。这是最直接的方式要求所有下游服务都信任同一个 AS并能验证该 JWT。务必注意不要将令牌传递给不受你控制或不需要知道用户身份的外部服务。模式二生成新令牌Token Exchange网关或中间服务可以使用自己的客户端凭证向 AS 发起一个“令牌交换”OAuth 2.0 Token Exchange请求为当前用户获取一个专门针对下游服务的新令牌。这提供了更好的审计追踪和权限隔离新令牌的 scope 可以更受限但增加了延迟和 AS 的负载。与服务网格集成在 Istio、Linkerd 等服务网格中通常由边车Sidecar代理来处理身份传递。你可以配置网格让它自动将来自入口网关的 JWT 中的用户身份信息如sub提取出来注入到内部服务调用的请求头中如X-Forwarded-User。这样业务服务无需再解析 JWT直接从请求头读取用户ID即可简化了 RS 的实现。5.4 监控、日志与审计AS 监控密切监控 AS 的端点调用频率、响应时间、错误率。异常的令牌请求峰值可能意味着攻击或客户端 bug。监控/token端点的不同授权类型grant_type分布。RS 监控在 RS 的日志中应记录每个受保护端点的访问至少包含时间戳、请求路径、HTTP 方法、用户标识sub、客户端标识client_id、授权结果允许/拒绝。注意不要记录完整的 JWT因为它是敏感凭证。可以记录 JWT 的签名部分或 JTI。集中式审计所有重要的安全事件都应在 AS 端进行集中审计记录包括用户登录成功/失败、用户同意授权、令牌颁发、令牌吊销、客户端配置变更等。这些日志应送入 SIEM安全信息和事件管理系统进行分析。分离架构的成功不仅在于技术组件的正确拼装更在于对边界和职责的持续坚守。让 AS 安心做它最擅长的“发牌员”让 RS 专注做它最拿手的“守门人”整个系统的安全性和可维护性自然会提升到一个新的层次。