.NET 6 InProcess Azure Function认证适配最新运行时问题求助

核心问题定位 #

Azure Functions 运行时4.1+对InProcess模式下的AspNetCore认证栈做了限制，原依赖Microsoft.AspNetCore.Authentication.JwtBearer等组件的方案会触发加载失败，根源是运行时宿主模型变更导致认证中间件无法正常注入。

替代方案1：手动实现令牌验证（绕过AspNetCore认证栈） #

直接在函数入口或自定义过滤器中手动验证JWT令牌，完全不依赖AspNetCore认证中间件：

• 从请求头提取Authorization中的Bearer令牌
• 使用System.IdentityModel.Tokens.Jwt包手动验证令牌的签名、发行方、受众、过期时间等核心属性
• 分别适配两种认证流的校验逻辑：
  • 隐式流：验证sub（用户ID）、scp（权限范围）等用户相关声明
  • 客户端凭证流：验证azp（客户端ID）、roles或scp（权限范围）声明
• 代码示例：

using System.IdentityModel.Tokens.Jwt;
using System.Security.Claims;
using System.Text;
using Microsoft.IdentityModel.Tokens;

public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req,
    ILogger log)
{
    var authHeader = req.Headers["Authorization"].FirstOrDefault();
    if (string.IsNullOrEmpty(authHeader) || !authHeader.StartsWith("Bearer "))
    {
        return new UnauthorizedResult();
    }

    var token = authHeader.Substring("Bearer ".Length);
    var tokenHandler = new JwtSecurityTokenHandler();
    var validationParams = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidIssuer = "你的Azure AD发行方地址",
        ValidateAudience = true,
        ValidAudience = "你的函数应用受众ID",
        ValidateIssuerSigningKey = true,
        // 若使用Azure AD，可从OpenID配置端点获取公钥，替换硬编码密钥
        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("你的令牌签名密钥")),
        ValidateLifetime = true,
        ClockSkew = TimeSpan.Zero
    };

    try
    {
        ClaimsPrincipal principal = tokenHandler.ValidateToken(token, validationParams, out _);
        // 区分两种认证流并校验权限
        var isClientCredentialFlow = principal.HasClaim(c => c.Type == "azp");
        if (isClientCredentialFlow)
        {
            var clientId = principal.FindFirst("azp")?.Value;
            // 验证客户端权限（如检查clientId是否在允许列表）
        }
        else
        {
            var userId = principal.FindFirst(ClaimTypes.NameIdentifier)?.Value;
            // 验证用户权限（如检查scp声明是否包含所需权限）
        }
    }
    catch (SecurityTokenException ex)
    {
        log.LogError("令牌验证失败：{Msg}", ex.Message);
        return new UnauthorizedResult();
    }

    // 执行业务逻辑
    return new OkObjectResult("认证通过");
}

替代方案2：使用Azure Functions自带的Easy Auth（推荐） #

利用Azure门户的Easy Auth（App Service Authentication）功能，完全托管认证逻辑：

• 在Azure门户开启Easy Auth，配置Azure AD作为身份提供商
• 针对隐式流：在Azure AD应用注册中开启"ID令牌"和"访问令牌"的隐式授权
• 针对客户端凭证流：在Azure AD中注册服务主体，配置Easy Auth允许该服务主体的令牌验证
• 函数代码中直接通过req.HttpContext.User获取已验证的Claims，无需手动处理令牌
• 优势：无需维护认证代码，自动适配运行时变更，同时支持多种认证流

修复DarkLoop.Azure.Functions.Authorization包的令牌验证问题 #

如果坚持使用该包，需调整配置避免冲突：

• 确保使用与当前运行时兼容的最新稳定版包
• 核对配置中的Issuer、Audience、签名密钥是否匹配，尤其是客户端凭证流的受众需对应服务主体的应用ID URI
• 移除Program.cs中所有AddAuthentication、AddJwtBearer等AspNetCore认证相关代码，避免冲突
• 配置示例（local.settings.json）：

{
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet",
    "DarkLoop:Auth:Schemes:Bearer:ValidIssuer": "你的Azure AD发行方地址",
    "DarkLoop:Auth:Schemes:Bearer:ValidAudience": "你的函数应用受众ID",
    "DarkLoop:Auth:Schemes:Bearer:IssuerSigningKey": "你的令牌签名密钥"
  }
}

解决Sync Triggers失败问题 #

• 若暂时无法适配最新运行时，可临时降级到4.1版本（不推荐长期使用）
• 检查函数身份权限：确保函数的系统/用户分配身份拥有存储账户等资源的访问权限
• 清理部署缓存：通过Kudu工具删除site/wwwroot下的旧文件后重新部署

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