如何为Azure Function App配置授权拦截未授权访问

你遇到的重启问题是Azure Function内置Easy Auth的平台级配置特性导致的，修改aud白名单属于应用配置变更，会触发工作进程回收，确实不适合多客户频繁接入的场景，下面几个方案可以做到完全同等的授权校验效果，且不会触发Function重启：

1. 自定义授权中间件/过滤器（无额外成本，最灵活） #

完全把授权逻辑放到你自己的代码里实现，不依赖平台内置的认证模块：

• 不管是进程内还是独立工作进程模型的Function，都可以注册自定义ASP.NET Core中间件，或者用Function全局过滤器，拦截所有入站HTTP请求
• 校验逻辑和你之前了解的aud规则完全一致：提取请求头里的Bearer Token，验证签名、过期时间、签发方(iss)合法性后，读取token里的aud声明，和你维护的可信aud列表做匹配，匹配通过放行，不通过直接返回401
• 注意不要把可信aud列表存在Function的App Settings或者本地配置文件里——修改这两类配置同样会触发重启。把列表存在支持动态读取的存储里就行，比如开了动态刷新的Azure App Configuration、Azure Cache for Redis、甚至业务数据库里，配置刷新间隔设30-60秒，新客户接入只要往存储里加一条aud记录，所有Function实例会自动读到新配置，全程无重启、不丢流量。
• 初学者如果觉得写中间件麻烦，也可以把这段校验逻辑抽成公共方法，在每个HTTP Trigger的入口先调用校验，效果完全一样。

2. 前置Azure API Management（APIM）做统一鉴权层（适合有API治理需求的场景） #

把鉴权逻辑从Function侧剥离到前置网关层：

• 先给Function App配置IP访问限制，只允许你自己的APIM实例IP访问，禁止外部请求直接打到Function
• 在APIM里配置JWT校验策略，统一做token签名、iss、aud的合法性校验，校验通过才把请求转发给后端Function
• 可信aud列表可以存在APIM的命名值或者策略里，修改APIM配置是网关层面的热更新，秒级生效，完全不会触发后端Function重启。除了鉴权之外你还可以顺便在APIM上做客户限流、请求日志、配额管控，适合客户量多了之后的API治理，消费级APIM的成本也很低，入门场景完全负担得起。

3. Easy Auth配通配aud规则（零代码，适合aud有统一命名规范的场景） #

如果你的所有接入客户用的token audience都符合统一的前缀规则（比如都是你自己Azure AD租户下注册的应用，aud统一为api://<your-function-domain>/customer-*格式），可以直接在Easy Auth里配置通配符aud匹配规则，新客户接入时只要按规则分配aud，完全不需要修改白名单配置，自然也不会触发重启。这个方案的限制是不适合客户用第三方IdP、aud命名无统一规则的场景。

• 不要只校验aud字段：必须同时校验token的签发方(iss)是你提前备案的可信身份源、token签名和对应IdP的公钥匹配、token在有效期内，避免攻击者伪造带合法aud的token绕过校验。
• 提前统一aud命名规范：给每个客户分配全局唯一的aud标识，建议按urn:<你的业务标识>:customer:<客户唯一ID>的规则生成，避免不同客户aud冲突，也方便后续审计。
• 加合理缓存：可信aud列表、IdP公钥都要加短时间缓存（比如5分钟），不要每次请求都查数据库、拉公钥，避免额外性能开销。
• 收好Function默认密钥：不管用哪种鉴权方案，都不要把Function的主机密钥、函数密钥直接发给客户，IP限制只放开信任的前置服务地址，避免攻击者绕过鉴权层直接访问Function。
• 留全审计日志：记录每个客户的接入时间、对应的aud、IdP信息，所有鉴权失败的请求也要打日志，方便后续异常排查和溯源。
• 新客户接入必须做联调：先在测试环境验证客户签发的token能正常通过校验、权限范围符合预期，再切生产流量，避免配置错误导致客户上线后访问异常。

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