为何已有OpenIdConnectHandler仍需使用OAuthHandler？

这事儿得从它们的继承关系和适用场景说起，咱们先把类的层级理清楚：

• 最基础的是 RemoteAuthenticationHandler<TOptions>，所有远程认证处理类的基类
• OAuthHandler<TOptions> 继承自它，是专门为纯OAuth2.0协议打造的通用处理框架
• OpenIdConnectHandler 同样继承自 RemoteAuthenticationHandler<OpenIdConnectOptions>，但它是针对OpenID Connect协议的专属实现——而OpenID Connect本身是在OAuth2.0基础上扩展出来的，多了身份认证相关的核心能力（比如ID Token、标准化的用户信息获取流程）

接下来分场景看为啥两者都需要：

1. 对接OpenID Connect身份提供商（比如IdentityServer） #

如果你要对接的是IdentityServer这种标准的OpenID Connect IDP，直接用OpenIdConnectHandler就够了。它已经封装了OpenID Connect协议的全流程：授权码请求、ID Token验证、用户信息拉取等等，你只需要在客户端注册时配置好相关参数就行，比如：

builder.Services.AddAuthentication()
    .AddOpenIdConnect("oidc", options =>
    {
        options.Authority = "https://your-identityserver-url";
        options.ClientId = "your-client-id";
        // 其他配置...
    });

2. 对接纯OAuth2.0的第三方服务（比如Facebook） #

但如果要对接的是Facebook这类只支持OAuth2.0、不遵循OpenID Connect规范的第三方登录服务，OpenIdConnectHandler就派不上用场了——这类服务没有ID Token，也不提供OpenID Connect定义的标准化用户信息端点。

这时候OAuthHandler<TOptions>就发挥作用了：它是纯OAuth2.0的通用处理类，像FacebookHandler就是专门继承它实现的Facebook登录适配。你可以基于它快速适配任何纯OAuth2.0的服务，自定义授权流程、用户信息获取逻辑等。

总结 #

简单说，两者的定位完全不同：

• OpenIdConnectHandler 是OAuth2.0的身份认证扩展实现，解决标准OpenID Connect场景的认证需求
• OAuthHandler<TOptions> 是纯OAuth2.0的通用处理框架，覆盖那些不支持OpenID Connect的第三方服务场景

所以它们是互补关系，各自解决不同的认证场景需求，自然都需要存在啦～

备注：内容来源于stack exchange，提问作者user25521292