Oauth 2.0 为什么每个OAuth2提供程序的工作方式都不同？

这让我很恼火，也许我只是弄错了，但似乎每个OAuth2提供商在使用他们的服务时都有自己的细微差别。OAuth2应该是处理身份验证的标准方式，为什么不呢？

好吧，如果你说的是OAuth2在理论上提供的4个流（

授权码

，

隐式

，

密码凭据

，

客户端凭据

），那么你是对的：大多数提供者不提供这4个流（通常只是前2个）

我的建议是选择授权代码流（如果可能的话），因为所有大型提供商（谷歌、雅虎、Outlook.com等）的流都是完全相同的

它们之间会发生什么变化：请求参数。因此，如果您为授权代码流编写一个通用代码（请求

auth

代码，通过

令牌进行交换），只需切换每个提供者的特定参数，就可以获得一个可重用的代码

更清楚一点：您可以使用
OAuth2
类来处理所有流，直到您获得令牌为止

然后URL和请求参数将属于提供者类，如
Google
，
Yahoo
，等等。将这些类作为参数传递给
OAuth2
。
OAuth2.0是一个协议框架，而不是协议本身。它允许在其上构建其他协议。这就是为什么有许多选项可供选择，而这些选项可能会使今天的事情变得有点复杂

此外，OAuth 2.0本身甚至根本不处理用户身份验证（请参见：），因为它不是一个身份验证协议，而是一个允许委托授权的协议

然而，一些提供商已经在OAuth2.0之上构建了自己的扩展来处理用户身份验证。在OAuth 2.0之上还定义了一个标准化的用户身份验证协议，其形式为OpenID Connect（）

希望在不久的将来，越来越多的提供商将其基于OAuth 2.0的用户身份验证协议迁移到OpenID Connect，我们消除了提供商在OpenID Connect尚未标准化时不得不构建的无数变体