OpenID是由OpenID基金会控制的一个开放标准和分散的身份验证协议。 OAuth是访问授权的开放标准。 OpenID连接(OIDC)结合了OpenID和OAuth的特性，即同时进行身份验证和授权。

OpenID采用由某个“OpenID提供者”即身份提供者(idP)管理的唯一URI的形式。

OAuth可以与XACML结合使用，其中OAuth用于所有权同意和访问委托，而XACML用于定义授权策略。

OIDC使用简单的JSON Web令牌(JWT)，您可以使用符合OAuth 2.0规范的流来获得它。OAuth与OIDC直接相关，因为OIDC是建立在OAuth 2.0之上的身份验证层。

例如，如果您选择使用谷歌帐户登录到Auth0，那么您使用的是OIDC。一旦您成功地使用谷歌进行身份验证并授权Auth0访问您的信息，谷歌将向Auth0发送有关用户和所执行的身份验证的信息。该信息以JSON Web令牌(JWT)的形式返回。您将收到一个访问令牌，如果需要，还会收到一个ID令牌。令牌类型:源:OpenID连接

类比: 一个组织使用ID卡作为识别目的，它包含芯片，它存储关于员工的详细信息以及授权，即校园/大门/ODC访问。ID卡作为OIDC，芯片作为OAuth。更多的例子和形式wiki

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

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

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

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

我目前正在研究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)

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

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

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

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

OAuth返回访问令牌，用于从资源服务器访问资源，OpenID返回JWT /加密令牌中关于资源的元数据细节

OAuth 2.0是一个安全协议。它既不是认证协议，也不是授权协议。

根据定义，身份验证回答了两个问题。

用户是谁? 用户当前是否在系统上?

OAuth 2.0具有以下授予类型

client_credentials:当一个应用程序需要与另一个应用程序交互并修改多个用户的数据时。 authorization_code:用户委托授权服务器发出access_token，客户端可以使用该token访问受保护的资源 refresh_token:当access_token过期时，可以利用刷新令牌获得一个新的access_token password:用户向调用授权服务器并接收access_token的客户机提供他们的登录凭据

这4个工具都有一个共同点，即access_token，这是一个可用于访问受保护资源的工件。

access_token没有提供“Authentication”协议必须回答的2个问题的答案。

一个解释Oauth 2.0的例子(来源:Oauth 2 in Action, Manning publications)

让我们来谈谈巧克力。我们可以用巧克力做很多甜点，包括软糖、冰淇淋和蛋糕。但是，这些都不能等同于巧克力，因为制作这种甜点还需要多种其他成分，如奶油和面包，尽管巧克力听起来像是主要成分。类似地，OAuth 2.0是巧克力，而cookie、TLS基础设施、身份提供者是提供“身份验证”功能所需的其他成分。

如果你需要身份验证，你可以使用OpenID Connect，它提供了一个“id_token”，除了access_token，它可以回答每个身份验证协议必须回答的问题。