授权在基础设施层与应用层实现的能力与侵入性权衡

认证解决”你是谁”，授权解决”你能做什么”，一旦身份可信，就不再需要区分 调用者是机器还是人，统一按角色做访问控制（RBAC）即可。Istio版本靠 AuthorizationPolicy这类基础设施配置实现分层授权：一条策略允许来自本 命名空间内部的流量访问指定端点的GET/POST/PUT/PATCH方法；另一条策略对 不带有效登录信息、且不是内部流量的外部请求，直接拒绝访问账户/支付/ 结算这几个敏感端点——这种”内部流量宽松、外部流量按身份收紧”的分层控制 完全靠YAML声明完成，不侵入业务代码，配置有source/to/when等多种匹配 维度（命名空间、路径、方法、JWT字段等），对大多数场景已经足够，但灵活性 终究比不上应用代码里手写的授权逻辑。Spring Cloud版本靠Spring Security 在应用层实现，有两种典型写法：一种是用ExpressionUrlAuthorizationConfigurer 做集中式URL匹配配置（如.antMatchers("/restful/pay/**").hasScope(Scope. SERVICE)），风格上和Istio的声明式配置比较接近，适合批量控制端点；另一种 是用JSR 250的@RolesAllowed或Spring的@PreAuthorize注解直接标注在每个 方法上，支持SpEL表达式做更精细的条件判断，代码侵入性更强（要分散写到 每个服务甚至每个方法），但换来的是可以做出比基础设施配置更精细的控制 效果。两种路径的取舍本质上和[[服务网格mTLS与应用层OAuth2认证的能力与 迁移平滑性差异]]一致：基础设施方案便捷、统一、无侵入但灵活性有限，应用层 方案灵活精细但要付出侵入性和开发成本。