Azure Function配置Header传密钥后Swagger POST请求报401未授权

两个异常现象的核心原因一致：你代码中添加的[OpenApiSecurity]特性仅用于生成Swagger/OpenAPI文档的元数据，完全不会修改Azure Functions运行时原生的密钥校验逻辑，也不会影响Azure门户生成端点URL的规则。

• Azure Functions 对AuthorizationLevel.Function级别的授权校验，原生仅识别两种密钥传递方式：URL查询字符串?code=<你的密钥>、HTTP请求头x-functions-key: <你的密钥>，根本不会读取你在OpenAPI配置中指定的名为code的请求头，因此Swagger按配置传code头时，运行时判定无有效密钥，返回401。
• Azure门户生成的端点URL是平台按照固定默认规则拼接的，不会读取你代码中的OpenAPI注解配置，因此始终会将密钥作为code查询参数附加在URL后，和你代码里的OpenAPI配置没有关联。
• 你之前用Postman测试可正常获取响应，是因为Postman请求的传参位置/参数名刚好匹配了运行时的校验规则，和Swagger传递code请求头的场景存在差异。

1. 修改OpenAPI安全配置的请求头名称，匹配Azure Functions运行时原生识别的头字段：

// 将原配置中 Name = "code" 修改为 Name = "x-functions-key"
[OpenApiSecurity("function_key", SecuritySchemeType.ApiKey, Name = "x-functions-key", In = OpenApiSecurityLocationType.Header)]

2. 重新编译部署函数应用，部署完成后清空Swagger页面缓存，在授权弹窗中重新填入函数密钥，此时Swagger发起请求时会自动将密钥放入x-functions-key请求头，即可正常通过授权校验。

如果你确实需要自定义密钥的请求头名称（例如坚持使用code作为请求头名），可以在函数应用的配置项中新增应用设置AzureWebJobsSecretHeaderName，将值设置为你需要自定义的头名code，重启应用后运行时就会识别对应头中传递的密钥。但需要注意：该自定义配置不会改变Azure门户生成端点URL的固定逻辑，门户始终会默认拼接?code=查询参数。

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