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

有三种方法可以比较OAuth和OpenID:

1. 目的

OpenID是为联邦身份验证而创建的，也就是说，允许第三方使用用户已经拥有的帐户为您验证用户身份。联合这个术语在这里非常重要，因为OpenID的全部意义在于可以使用任何提供者(白名单除外)。你不需要预先选择或与提供商协商协议，以允许用户使用他们拥有的任何其他帐户。

OAuth的创建是为了消除用户与第三方应用程序共享密码的需要。它实际上是作为解决OpenID问题的一种方式开始的:如果您在站点上支持OpenID，则不能使用HTTP基本凭据(用户名和密码)来提供API，因为用户在站点上没有密码。

The problem is with this separation of OpenID for authentication and OAuth for authorization is that both protocols can accomplish many of the same things. They each provide a different set of features which are desired by different implementations but essentially, they are pretty interchangeable. At their core, both protocols are an assertion verification method (OpenID is limited to the 'this is who I am' assertion, while OAuth provides an 'access token' that can be exchanged for any supported assertion via an API).

2. 特性

这两种协议都为站点提供了一种方法，可以将用户重定向到其他地方，然后返回一个可验证的断言。OpenID提供身份断言，而OAuth以访问令牌的形式更为通用，可用于“向OAuth提供者询问问题”。但是，它们各自支持不同的特性:

OpenID - the most important feature of OpenID is its discovery process. OpenID does not require hard coding each the providers you want to use ahead of time. Using discovery, the user can choose any third-party provider they want to authenticate. This discovery feature has also caused most of OpenID's problems because the way it is implemented is by using HTTP URIs as identifiers which most web users just don't get. Other features OpenID has is its support for ad-hoc client registration using a DH exchange, immediate mode for optimized end-user experience, and a way to verify assertions without making another round-trip to the provider.

OAuth - the most important feature of OAuth is the access token which provides a long lasting method of making additional requests. Unlike OpenID, OAuth does not end with authentication but provides an access token to gain access to additional resources provided by the same third-party service. However, since OAuth does not support discovery, it requires pre-selecting and hard-coding the providers you decide to use. A user visiting your site cannot use any identifier, only those pre-selected by you. Also, OAuth does not have a concept of identity so using it for login means either adding a custom parameter (as done by Twitter) or making another API call to get the currently "logged in" user.

3.技术的实现

这两种协议在使用重定向获取用户授权方面具有共同的架构。在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游乐场。

(源)

现在OpenID连接是最相关的，所以我将解释OpenID连接和OAuth 2之间的区别。

OpenID connect指定IDToken标准:https://openid.net/specs/openid-connect-core-1_0.html#IDToken

这是OpenID连接的主要贡献。因此，它指定了身份验证完成后响应中应该包含的内容。

IDToken需要是JWT令牌，并包含用户的信息，如用户id、用户名等。返回的信息取决于授权时传递的请求。它还包含令牌的过期日期，并且应该包含令牌的数字签名。此签名用于使用公钥验证令牌。

第二大差异与公钥有关。OpenID连接使用所谓的发现或众所周知的端点。它是一个公开开放的端点，只返回一个带有公钥和授权端点等值的JSON。

https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedDiscovery

因此OpenID本质上是与身份验证相关的，因为它指定了IDToken，这是通过检查数字签名和IDToken的过期日期来验证用户身份所必需的。

OAuth处理授权，特别是与作用域和验证资源服务器上的访问令牌相关的授权。

但是，正如这里所写的，OpenID使用OAuth 2授权进行身份验证。

https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

身份验证请求是OAuth 2.0授权请求，它请求授权服务器对最终用户进行身份验证。

简而言之，尝试将OpenID视为使用JWT令牌的身份验证，将OAuth视为具有作用域的授权。

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，它可以回答每个身份验证协议必须回答的问题。

我想谈谈这个问题的一个特定方面，如以下评论所述:

OAuth:在授予某些特性的访问权限之前，必须进行身份验证，对吗?所以OAuth =什么OpenId +授予访问某些功能?- Hassan Makarov 6月21日1:57

是的……也没有。答案很微妙，所以请耐心听我说。

当OAuth流将您重定向到目标服务(即OAuth提供者)时，您很可能需要在将令牌交还给客户机应用程序/服务之前使用该服务进行身份验证。然后，生成的令牌允许客户端应用程序代表给定用户发出请求。

注意最后一句话的一般性:具体来说，我写的是“代表给定用户”，而不是“代表您”。一个常见的错误是假设“拥有与给定用户拥有的资源交互的能力”意味着“您和目标资源的所有者是同一人”。

不要犯这样的错误。

虽然您确实使用OAuth提供者进行身份验证(例如，通过用户名和密码，或者SSL客户端证书或其他方式)，但客户端获得的回报不应该被视为身份证明。例如，在一个流中，对另一个用户的资源的访问被委托给您(通过代理，OAuth客户端)。授权并不意味着身份验证。

要处理身份验证，您可能需要研究OpenID Connect，它本质上是OAuth 2.0设置的基础之上的另一层。以下是关于OpenID Connect(在我看来)最突出的一点(来自https://oauth.net/articles/authentication/):)

OpenID Connect is an open standard published in early 2014 that defines an interoperable way to use OAuth 2.0 to perform user authentication. In essence, it is a widely published recipe for chocolate fudge that has been tried and tested by a wide number and variety of experts. Instead of building a different protocol to each potential identity provider, an application can speak one protocol to as many providers as they want to work with. Since it's an open standard, OpenID Connect can be implemented by anyone without restriction or intellectual property concerns. OpenID Connect is built directly on OAuth 2.0 and in most cases is deployed right along with (or on top of) an OAuth infrastructure. OpenID Connect also uses the JSON Object Signing And Encryption (JOSE) suite of specifications for carrying signed and encrypted information around in different places. In fact, an OAuth 2.0 deployment with JOSE capabilities is already a long way to defining a fully compliant OpenID Connect system, and the delta between the two is relatively small. But that delta makes a big difference, and OpenID Connect manages to avoid many of the pitfalls discussed above by adding several key components to the OAuth base: [...]

The document then goes on to describe (among other things) token IDs and a UserInfo endpoint. The former provides a set of claims (who you are, when the token was issued, etc, and possibly a signature to verify the authenticity of the token via a published public key without having to ask the upstream service), and the latter provides a means of e.g. asking for the user's first/last name, email, and similar bits of info, all in a standardized way (as opposed to the ad-hoc extensions to OAuth that people used before OpenID Connect standardized things).