Open ID Connect为标准协议，ASP.NET Core 5为何需特定认证包？

完全可以通过通用OIDC认证方案，仅修改配置参数来适配任意标准OIDC身份提供商，无需依赖专属的扩展方法或NuGet包。

通用OIDC配置示例 #

在ASP.NET Core 5中，直接使用AddOpenIdConnect方法即可完成通用配置，无需依赖厂商专属方法：

using Microsoft.AspNetCore.Authentication.Cookies;
using Microsoft.AspNetCore.Authentication.OpenIdConnect;

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(options =>
    {
        options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
    })
    .AddCookie()
    .AddOpenIdConnect(options =>
    {
        // 核心配置参数，仅需修改这几个即可对接标准OIDC提供商
        options.Authority = "https://your-organization-oidc-authority.com";
        options.ClientId = "your-client-id";
        options.ClientSecret = "your-client-secret";
        
        // OIDC标准流程配置
        options.ResponseType = "code";
        options.SaveTokens = true;
        
        // 若提供商有特殊要求，可添加额外配置（如回调路径、Claims映射等）
        // options.CallbackPath = "/signin-oidc";
        // options.MapInboundClaims = false;
    });

    // 其他服务配置...
}

为何存在厂商专属方法/包？ #

那些厂商专属的AddGoogle()、AddFacebook()或Auth0专属包，本质是封装了厂商特有的非标准细节，目的是简化开发：

• 内置扩展方法（如AddGoogle）：谷歌、脸书等厂商虽然基于OIDC/OAuth2，但存在一些自定义规则，比如默认回调路径、特定的Claims映射、额外的权限参数等，微软将这些细节封装成快捷方法，减少开发者手动配置的工作量。你完全可以用通用AddOpenIdConnect替代这些方法，只要手动补全这些厂商特有的配置项。
• 第三方专属包（如Auth0的包）：这类包通常提供了厂商额外的增值功能，比如简化的API权限管理、自定义规则集成、专属错误处理等，这些并非OIDC标准要求的功能，属于可选的增值服务，而非对接的必要条件。

测试建议 #

如果无法对接内部提供商测试，可以使用公开的OIDC测试服务（如搭建本地Keycloak实例、使用IdentityServer4的演示项目），通过通用配置验证认证流程是否正常。

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