Istio中RequestAuthentication与AuthorizationPolicy执行顺序咨询

核心结论 #

Istio 中CUSTOM 动作的 AuthorizationPolicy（外部授权器）默认在 RequestAuthentication 之前执行，这是和 ALLOW/DENY 类型授权策略的关键区别——ALLOW/DENY 确实是在认证完成后执行，所以能直接引用 JWT 声明。你的测试结果完全符合 Istio 的默认设计逻辑，并非配置错误。

为什么会出现你的测试现象 #

• 外部授权器先触发：默认情况下，Istio 会优先调用外部授权器，此时 RequestAuthentication 还未完成 JWT 验证，你配置的x-forwarded-jwt-payload头还未生成，自然无法传递到外部授权器。
• 过期 Token 未被 Istio 拦截：因为外部授权器先于 RequestAuthentication 处理请求，过期 Token 还没进入 Istio 的认证环节就被外部授权器拒绝了。

实现「先认证后外部授权」的解决方案 #

如果你需要让 RequestAuthentication 先完成基础 Token 验证，再调用外部授权器做额外校验，可以修改外部授权器的 Provider 配置，指定其在认证后阶段执行：

apiVersion: istio.io/v1alpha1
kind: ExtensionProvider
metadata:
  name: ext-authz-http
  namespace: istio-system
spec:
  envoyExtAuthzHttp:
    service: "你的外部授权器服务地址"
    port: "服务端口"
    filterPhase: POST_AUTHN # 关键配置：将外部授权器的执行阶段设置为认证后

配置完成后，Istio 会先执行 RequestAuthentication 完成 JWT 验证，生成x-forwarded-jwt-payload头，再调用外部授权器。此时过期 Token 会被 Istio 直接拦截，外部授权器也能拿到已验证的 JWT 载荷，避免重复验证。

补充说明 #

ALLOW/DENY 类型的 AuthorizationPolicy 之所以能基于 JWT 声明做规则判断，是因为这类授权策略的执行阶段固定在认证之后，此时 RequestAuthentication 已经完成身份校验并提取了 JWT 中的声明信息。而 CUSTOM 类型的授权策略默认设计为支持参与认证流程（比如外部授权器自行处理 Token 验证），所以默认执行阶段在认证之前。

内容的提问来源于stack exchange，提问作者maglite