ASP.Net Core 2.0中用纯OAuth 2.0替代OpenId Connect对接Azure AD咨询

我完全理解你的处境——合作厂商不支持OpenId Connect，得把原本依赖Azure AD OIDC的认证流程改成纯OAuth 2.0授权码流程。下面是具体的实现步骤和代码示例，一步步帮你完成改造：

1. 清理原有OIDC相关配置 #

首先把项目里基于OpenId Connect的配置代码移除，比如：

// 删掉这类默认的Azure AD OIDC配置
services.AddAzureAD(options => Configuration.Bind("AzureAd", options));
// 或者直接移除OpenId Connect的注册代码
services.AddOpenIdConnect("AzureAD", options => { /* ... 原有配置 ... */ });

2. 配置纯OAuth 2.0授权码流程 #

改用AddOAuth方法来搭建纯OAuth 2.0认证体系，核心是指定厂商的OAuth端点、你的应用凭证，以及处理令牌后的用户身份构建：

services.AddAuthentication(options =>
{
    // 用Cookie保存认证状态
    options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    // 指定默认的挑战方案为我们自定义的厂商OAuth
    options.DefaultChallengeScheme = "VendorOAuth";
})
.AddCookie() // 注册Cookie认证中间件
.AddOAuth("VendorOAuth", options =>
{
    // 填写厂商提供的OAuth 2.0核心端点
    options.AuthorizationEndpoint = "https://vendor.example.com/oauth/authorize";
    options.TokenEndpoint = "https://vendor.example.com/oauth/token";
    // 如果厂商提供用户信息端点，后续用来拉取用户身份详情
    options.UserInformationEndpoint = "https://vendor.example.com/oauth/userinfo";

    // 你的应用在厂商平台注册的ClientId和ClientSecret
    options.ClientId = Configuration["VendorOAuth:ClientId"];
    options.ClientSecret = Configuration["VendorOAuth:ClientSecret"];

    // 授权回调路径，必须和你在厂商平台注册的回调地址完全一致
    options.CallbackPath = new PathString("/signin-vendor");

    // 根据厂商要求申请必要的授权范围
    options.Scope.Add("profile");
    options.Scope.Add("email");
    // 有些厂商可能要求带上openid范围，但这里只是纯OAuth，不是OIDC

    // 处理令牌获取后的用户身份构建逻辑
    options.Events = new OAuthEvents
    {
        OnCreatingTicket = async context =>
        {
            // 调用厂商的用户信息端点，获取用户详情
            var request = new HttpRequestMessage(HttpMethod.Get, context.Options.UserInformationEndpoint);
            request.Headers.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
            request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", context.AccessToken);

            var response = await context.Backchannel.SendAsync(request, HttpCompletionOption.ResponseHeadersRead, context.HttpContext.RequestAborted);
            response.EnsureSuccessStatusCode();

            var userInfo = JsonDocument.Parse(await response.Content.ReadAsStringAsync()).RootElement;

            // 将厂商返回的用户信息映射到ClaimsIdentity，用于后续身份识别
            context.Identity.AddClaim(new Claim(ClaimTypes.NameIdentifier, userInfo.GetProperty("user_id").GetString()));
            context.Identity.AddClaim(new Claim(ClaimTypes.Name, userInfo.GetProperty("username").GetString()));
            context.Identity.AddClaim(new Claim(ClaimTypes.Email, userInfo.GetProperty("email").GetString()));
            // 可根据厂商返回的字段添加更多自定义Claim
        }
    };
});

3. 确保认证中间件在管道中生效 #

在Startup.cs的Configure方法里，要保证UseAuthentication和UseAuthorization的顺序正确，放在路由中间件之前：

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ... 其他中间件（比如异常处理、静态文件等）

    app.UseAuthentication(); // 启用认证
    app.UseAuthorization();  // 启用授权

    // ... 路由、MVC等中间件
}

4. 关键注意事项 #

• 端点校验：务必确认厂商提供的授权、令牌、用户信息端点完全符合OAuth 2.0标准，避免因端点格式差异导致流程卡壳。
• 回调路径一致性：CallbackPath必须和你在厂商平台注册的回调地址完全匹配，否则厂商会拒绝回调请求。
• 令牌有效性验证：纯OAuth 2.0没有OIDC的ID Token签名验证机制，你需要根据厂商文档，通过令牌 introspection 端点或者其他方式验证Access Token的有效性。
• Scope权限：根据实际业务需求申请合适的授权范围，确保能获取到足够的用户信息来构建身份。

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