创建这两个协议的原因不同。创建OAuth是为了授权第三方访问资源。创建OpenID是为了执行分散的身份验证。本网站说明如下:

OAuth是一种用于验证终端用户身份并向第三方授予权限的协议。这个验证的结果是一个令牌。第三方可以使用这个令牌来代表用户访问资源。令牌有一个作用域。作用域用于验证用户是否可以访问某个资源

OpenID是用于分散身份验证的协议。认证是关于身份的;确定用户实际上就是他所声称的那个人。去中心化意味着该服务不知道需要保护的任何资源或应用程序的存在。这就是OAuth和OpenID之间的关键区别。

OpenID、OAuth、OpenID Connect的区别解释:

OpenID is a protocol for authentication while OAuth is for authorization. Authentication is about making sure that the guy you are talking to is indeed who he claims to be. Authorization is about deciding what that guy should be allowed to do. In OpenID, authentication is delegated: server A wants to authenticate user U, but U's credentials (e.g. U's name and password) are sent to another server, B, that A trusts (at least, trusts for authenticating users). Indeed, server B makes sure that U is indeed U, and then tells to A: "ok, that's the genuine U". In OAuth, authorization is delegated: entity A obtains from entity B an "access right" which A can show to server S to be granted access; B can thus deliver temporary, specific access keys to A without giving them too much power. You can imagine an OAuth server as the key master in a big hotel; he gives to employees keys which open the doors of the rooms that they are supposed to enter, but each key is limited (it does not give access to all rooms); furthermore, the keys self-destruct after a few hours. To some extent, authorization can be abused into some pseudo-authentication, on the basis that if entity A obtains from B an access key through OAuth, and shows it to server S, then server S may infer that B authenticated A before granting the access key. So some people use OAuth where they should be using OpenID. This schema may or may not be enlightening; but I think this pseudo-authentication is more confusing than anything. OpenID Connect does just that: it abuses OAuth into an authentication protocol. In the hotel analogy: if I encounter a purported employee and that person shows me that he has a key which opens my room, then I suppose that this is a true employee, on the basis that the key master would not have given him a key which opens my room if he was not.

(源)

OpenID Connect与OpenID 2.0有何不同? OpenID Connect执行许多与OpenID 2.0相同的任务，但确实如此 以一种api友好的方式，在本地和移动设备上都可用 应用程序。OpenID Connect为健壮性定义了可选机制 签名和加密。而OAuth 1.0a和OpenID的集成 2.0需要一个扩展，在OpenID连接中，OAuth 2.0功能与协议本身集成。

(源)

OpenID connect will give you an access token plus an id token. The id token is a JWT and contains information about the authenticated user. It is signed by the identity provider and can be read and verified without accessing the identity provider. In addition, OpenID connect standardizes quite a couple things that oauth2 leaves up to choice. for instance scopes, endpoint discovery, and dynamic registration of clients. This makes it easier to write code that lets the user choose between multiple identity providers.

(源)

谷歌是2.0版的

谷歌的OAuth 2.0 api可用于身份验证和 授权。本文档描述了我们的OAuth 2.0实现 用于身份验证，符合OpenID Connect 规范，并且是OpenID认证。在 “OAuth 2.0访问谷歌接口”也适用于本业务。如果 如果您想以交互方式探索此协议，我们推荐 谷歌OAuth 2.0游乐场。

(源)

创建这两个协议的原因不同。创建OAuth是为了授权第三方访问资源。创建OpenID是为了执行分散的身份验证。本网站说明如下:

OAuth是一种用于验证终端用户身份并向第三方授予权限的协议。这个验证的结果是一个令牌。第三方可以使用这个令牌来代表用户访问资源。令牌有一个作用域。作用域用于验证用户是否可以访问某个资源

OpenID是用于分散身份验证的协议。认证是关于身份的;确定用户实际上就是他所声称的那个人。去中心化意味着该服务不知道需要保护的任何资源或应用程序的存在。这就是OAuth和OpenID之间的关键区别。

OpenID和OAuth都是用于身份验证和/或授权的基于http的协议。两者都旨在允许用户执行操作，而无需向客户端或第三方提供身份验证凭据或全面权限。虽然它们是相似的，并且有建议将它们一起使用的标准，但它们是单独的协议。

OpenID用于联合身份验证。客户机接受来自任何提供者的身份断言(尽管客户机可以自由地将提供者列入白名单或黑名单)。

OAuth用于委托授权。客户端向提供者注册，提供者提供授权令牌，客户端接受这些授权令牌以代表用户执行操作。

OAuth目前更适合于授权，因为身份验证后的进一步交互被内置到协议中，但这两个协议都在不断发展。OpenID及其扩展可用于授权，OAuth可用于身份验证，可以将其视为无操作授权。

OpenID是关于身份验证的。证明你是谁)，OAuth是关于授权(即。授予对功能/数据等的访问权。而不必处理原始的身份验证)。

OAuth可以在外部合作伙伴站点中使用，允许访问受保护的数据，而无需重新对用户进行身份验证。

博客文章“从用户的角度看OpenID与OAuth”从用户的角度对两者进行了简单的比较，而“OAuth-OpenID:如果你认为它们是同一件事，你就找错了对象”有更多的信息。

我目前正在研究OAuth 2.0和OpenID连接规范。以下是我的理解: 之前他们是:

OpenID was proprietary implementation of Google allowing third party applications like for newspaper websites you can login using google and comment on an article and so on other usecases. So essentially, no password sharing to newspaper website. Let me put up a definition here, this approach in enterprise approach is called Federation. In Federation, You have a server where you authenticate and authorize (called IDP, Identity Provider) and generally the keeper of User credentials. the client application where you have business is called SP or Service Provider. If we go back to same newspaper website example then newspaper website is SP here and Google is IDP. In enterprise this problem was earlier solved using SAML. that time XML used to rule the software industry. So from webservices to configuration, everything used to go to XML so we have SAML, a complete Federation protocol OAuth: OAuth saw it's emergence as an standard looking at all these kind of proprietary approaches and so we had OAuth 1.o as standard but addressing only authorization. Not many people noticed but it kind of started picking up. Then we had OAuth 2.0 in 2012. CTOs, Architects really started paying attention as world is moving towards Cloud computing and with computing devices moving towards mobile and other such devices. OAuth kind of looked upon as solving major problem where software customers might give IDP Service to one company and have many services from different vendors like salesforce, SAP, etc. So integration here really looks like federation scenario bit one big problem, using SAML is costly so let's explore OAuth 2.o. Ohh, missed one important point that during this time, Google sensed that OAuth actually doesn't address Authentication, how will IDP give user data to SP (which is actually wonderfully addressed in SAML) and with other loose ends like: a. OAuth 2.o doesn't clearly say, how client registration will happen b. it doesn't mention anything about the interaction between SP (Resource Server) and client application (like Analytics Server providing data is Resource Server and application displaying that data is Client)

从技术上讲，这里已经给出了很好的答案，我想到了给出简要的进化观点