现在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在授权之上构建身份验证:用户将对其身份的访问委托给应用程序，然后应用程序成为身份API的消费者，从而找出是谁首先授权了客户端http://oauth.net/articles/authentication/

如果您的用户只是想登录Facebook或Twitter，请使用OAuth。如果您的用户是运行自己的OpenID提供者的用户，请使用OpenID，因为他们“不希望其他人拥有自己的身份”。

OpenId -仅用于身份验证。

OAuth—用于身份验证和授权。授权依赖于access_token，它是JWT令牌的一部分。它可以包含用户权限的详细信息或任何有用的信息。

两者都可以依赖第三方认证提供商来维护他们的帐户。例如，OKTA身份提供者，User在OKTA登录页面上提供凭据，在成功登录时，用户被重定向到消费者应用程序，头部有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中，用户授权访问他们的身份。但这就是他们所有的共同点。

每个协议都有不同的方法来计算用于验证请求或响应的真实性的签名，并且每个协议都有不同的注册要求。

更多的是对问题的延伸而不是答案，但它可能会为上面伟大的技术答案增加一些视角。我是一个在很多领域都很有经验的程序员，但是在网页编程方面完全是个新手。现在尝试使用Zend框架构建一个基于web的应用程序。

Definitely will implement an application-specific basic username/password authentication interface, but recognize that for a growing number of users the thought of yet another username and password is a deterrent. While not exactly social networking, I know that a very large percentage of the application's potential users already have facebook or twitter accounts. The application doesn't really want or need to access information about the user's account from those sites, it just wants to offer the convenience of not requiring the user to set up new account credentials if they don't want to. From a functionality point of view, that would seem a poster child for OpenID. But it seems that neither facebook nor twitter are OpenID providers as such, though they do support OAuth authentication to access their user's data.

在我读过的所有关于这两者及其区别的文章中，直到我看到上面Karl Anderson的观察，“OAuth可以用于身份验证，这可以被认为是一种无操作授权”，我才看到任何明确的确认OAuth足以满足我想要做的事情。

In fact, when I went to post this "answer", not being a member at the time, I looked long and hard at the bottom of this page at the options for identifying myself. The option for using an OpenID login or obtaining one if I didn't have one, but nothing about twitter or facebook, seemed to suggest that OAuth wasn't adequate for the job. But then I opened another window and looked for the general signup process for stackoverflow - and lo and behold there's a slew of 3rd-party authentication options including facebook and twitter. In the end I decided to use my google id (which is an OpenID) for exactly the reason that I didn't want to grant stackoverflow access to my friends list and anything else facebook likes to share about its users - but at least it's a proof point that OAuth is adequate for the use I had in mind.

It would really be great if someone could either post info or pointers to info about supporting this kind of multiple 3rd-part authorization setup, and how you deal with users that revoke authorization or lose access to their 3rd party site. I also get the impression that my username here identifies a unique stackoverflow account that I could access with basic authentication if I wanted to set it up, and also access this same account through other 3rd-party authenticators (e.g. so that I would be considered logged in to stackoverflow if I was logged in to any of google, facebook, or twitter...). Since this site is doing it, somebody here probably has some pretty good insight on the subject. :-)

很抱歉这篇文章写了这么长时间，而且更多的是一个问题而不是一个答案——但是Karl的评论似乎是在OAuth和OpenID上大量的帖子中最合适的地方。如果我没有找到更好的地方，我提前道歉，我确实试过了。