网关认证：验证身份之后还要守住哪些入口

网关把外部请求集中接进来，可以分发请求、检查身份、做粗略权限控制和限制流量，但通常不知道每笔订单属于谁。认证回答调用者是谁，授权回答他能不能操作这条资源。用户登录成功，仍可能无权改别人订单；网关核验通过以后，下游还要按对象、租户和状态检查业务权限。

JWT 能解码出内容，不代表内容可信。要按允许的算法和可信密钥验证签名，再检查发行方、有效时间及应用要求的接收方，还要明确令牌用途和权限怎样对应。其他系统签发的有效 JWT，也不应随意用于当前服务。令牌核验应交给成熟安全组件，不能拿 Base64 解码代替认证。

身份传播也有信任边界。客户端自己带来的 X-User-Id 不是证据，网关若添加内部身份信息，必须先清理伪造输入并通过受保护链路传递，下游要验证调用来源或重新验证令牌。TokenRelay 的职责是转发适用的访问令牌，不会自动给令牌扩大受众或给用户授予订单权限。直接绕过网关的入口同样需要纳入部署与授权设计。

这里有两层过滤流程。Spring Security 通过 WebFlux 的 WebFilter 处理身份认证和访问权限；Gateway 匹配到路由后，才把全局过滤器 GlobalFilter 与该路由的 GatewayFilter 组合起来。

后一条链中，请求进入时按优先顺序执行，响应返回时再反向经过对应的后续逻辑。理解顺序时，要先问自己正在看哪一层，再看排序值。不能因为某个 GlobalFilter 的顺序很靠前，就认为它会在所有请求的所有安全检查之前运行。

响应式代码描述的是订阅后执行的流水线。读取数据库、调用远端鉴权或读取大文件若直接阻塞事件循环，会拖慢共享线程上的其它连接。确需接入阻塞边界时，应采用受控执行器、并发上限和超时，并理解切换线程后普通 ThreadLocal 可能不再代表当前请求。认证信息应沿受支持的安全上下文传播，而不是在某线程存一个用户对象后期待它永远有效。

对订单修改可分两道判断：网关检查访问令牌和 orders:write 之类的能力，下游结合可信 userId、tenantId、订单 ownerId 与订单状态作最终授权。数据查询应在数据库条件中限定租户和归属，避免先返回整条敏感对象再在前端隐藏。批量操作要逐项或用统一约束核对全部对象，不能只验证列表第一项就放行整批。

这段实现先从 ReactiveSecurityContextHolder 取出 Authentication，再交给 authorizationManager.verify，结合当前 ServerWebExchange 判断是否允许请求继续。这里不负责执行 JWT 签名算法，也不会自动理解全部业务角色规则。要查清身份为什么可信、权限具体怎么判断，需要继续看前面的认证组件和配置的授权管理器。

verify 返回 Mono<Void>，用“正常完成”表示校验通过，用“出错”表示失败，不需要再返回一个业务值。因此，没有值但正常完成，并不等于没有作出授权判断。AccessDeniedException 会沿错误处理路径继续传递，日志只是记录结果，不能代替判断。读 switchIfEmpty 时，要看它作用于链条中的哪一步，分清没有元素、正常完成和报错各自代表什么。

普通 ThreadLocal 依赖线程，而响应式请求可能在不同线程继续。真实实现使用响应式安全上下文，说明身份应与订阅链条关联，不能仅靠某个线程曾经处理过这个用户。自定义过滤器若跨执行器或自行 subscribe，可能丢失上下文或脱离正常响应生命周期，既影响授权也影响错误处理。

模型将缺少身份固定为拒绝，是针对受保护路由的教学约定。实际公开端点、匿名身份与多条安全链要通过明确配置表达，并对匹配顺序做测试。不能把模型直接复制为“所有路径都一样”的框架替代物；源码理解的重点是验证由哪个策略作裁决、失败是否阻止后续执行，以及资源级规则是否在正确层出现。

给定用户已验证角色集合、角色继承有向图及各角色权限集合，计算继承后的有效权限，再移除显式拒绝集合。继承图允许错误配置的环，算法必须终止；未知角色默认不产生权限。结果按权限名排序。

角色继承是一个有向可达性问题。用户具有 admin，就需要检查从 admin 沿父角色边可以到达的全部角色，再收集它们的权限。使用队列做广度优先遍历，visited 记录已经处理过的角色；没有这个集合，配置中的环会造成无限遍历，多条路径到同一角色也会重复收集。

先合并允许权限，再统一移除显式拒绝，定义拒绝优先的规则。这样无论某个权限被多少个角色授予，只要它在拒绝集合中就不能出现在结果里。真实权限系统可能采用不同策略组合语义，所以必须在接口契约中固定规则，不能让遍历顺序决定“最后遇到允许还是拒绝”。

角色闭包只计算粗粒度能力，不包含订单归属。得到 orders:write 后，仍应在具体订单请求中判断租户、owner、状态等属性。用一个返回 Set 的算法替代全部授权，会把“允许操作某类资源”错误扩大为“允许操作任意实例”。算法测试因此专门包含未知角色与空身份，确保没有配置就不会凭空获得能力。

V、E 是可达角色与继承边数，G 是这些角色的权限条目数，A 是移除显式拒绝前的唯一权限数，U 是最终有效权限数。visited 在出队时去重，每个角色只展开一次，但同一角色仍可被重复入队，队列峰值需要计入 O(E)。中间权限集合即使最终被全部拒绝也占 O(A)。散列集合通常均摊常数；输出排序为 O(U log U)，长名称还要计入字符处理成本。

网关把什么交给下游、下游相信哪些信息，需要提前约定。下游若接收原访问令牌，应检查令牌是否发给自己使用，以及权限是否够用；若使用内部服务凭据，则要验证调用服务的身份，并保证传来的用户信息没有被篡改、没有超出允许范围。转发令牌不会自动变成令牌交换，也不会增加权限。管理和调试入口同样要做授权检查，不能仅凭地址在内网就信任来访请求。

JWT 验证应使用成熟组件并固定可信配置，及时处理密钥轮换、时钟偏差和未知 key id。受众校验往往需要应用显式配置，不能假定默认签名校验已经覆盖所有业务声明。日志记录授权结果、拒绝原因类别和关联 ID 即可，避免打印完整令牌、密码或敏感请求体。错误响应也不应泄漏其它租户资源的详细存在性。

验收用多类请求覆盖边界：无令牌、过期令牌、错误发行方或受众、权限不足、伪造内部身份头、合法身份访问他人资源，以及批量列表中的混合归属。每次同时核对响应与数据库是否无副作用。测试环境中从下游直连入口发起同类请求，验证部署边界与应用授权都符合设计，不能只测浏览器隐藏了哪些按钮。