微服务架构中，服务之间频繁通信，确保请求来源合法、操作权限合规是安全的核心。认证与授权不能依赖单体时代的会话机制，需采用更灵活、可扩展的方式实现。
使用API网关统一处理入口认证
所有外部请求先经过API网关，网关负责验证身份，比如校验JWT令牌或调用OAuth2服务器确认访问凭证。通过后，网关将用户信息注入请求头（如
X-User-ID、
X-Roles），再转发给内部服务。
这样做避免每个服务重复实现认证逻辑，也减少了暴露认证逻辑的风险。
网关可集成OAuth2客户端或JWT解析模块 验证通过后添加可信的用户上下文头 未通过直接拦截，不进入内网服务服务间调用使用短期令牌或mTLS
内部服务之间的通信应启用双向认证，防止非法服务接入。常用方式包括：
JWT令牌传递：上游服务携带从网关获得的原始或派生JWT调用下游，下游服务通过共享密钥或公钥验证签名 mTLS（双向TLS）：每个服务拥有证书，通信前互相验证身份，适合高安全场景 服务账号令牌：非用户触发的服务间调用使用预置的service account token，类似API密钥但有生命周期管理关键点是确保令牌有效期短，并通过安全通道（HTTPS）传输。
基于上下文的细粒度授权
即使通过认证，也不代表能执行所有操作。每个服务需根据请求中的用户角色、组织归属、数据权限等做本地授权判断。
常见做法：
从请求头提取X-User-ID和
X-Roles，结合业务规则决定是否放行 调用集中式策略引擎（如Open Policy Agent），将决策逻辑外置，便于统一管理 敏感操作记录审计日志，供后续追溯
集中管理用户身份与权限
推荐使用统一的身份提供商（IdP），如Keycloak、Auth0或自建OAuth2/OpenID Connect服务。用户登录后获取令牌，后续服务都信任该令牌签发方。
角色和权限配置在IdP中维护，服务只负责解析和执行，降低耦合。
避免在各服务中硬编码权限规则 支持动态调整用户权限，即时生效基本上就这些。核心思路是：入口统一认证、服务间可信通信、按需授权、身份集中管理。不复杂但容易忽略细节，比如头伪造防护或令牌泄露应对。
