OpenId使用OAuth来处理身份验证。

通过类比，就像。net依赖于Windows API。你可以直接调用Windows API，但是它太宽了，太复杂了，方法参数太大了，你很容易犯错误/bug /安全问题。

OpenId/OAuth也是如此。OpenId依赖于OAuth来管理身份验证，但定义了特定的令牌(Id_token)、数字签名和特定的流。

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).

很多人仍然访问这个网站，这里有一个非常简单的图表来解释它

礼貌维基百科

更多的是对问题的延伸而不是答案，但它可能会为上面伟大的技术答案增加一些视角。我是一个在很多领域都很有经验的程序员，但是在网页编程方面完全是个新手。现在尝试使用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上大量的帖子中最合适的地方。如果我没有找到更好的地方，我提前道歉，我确实试过了。

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

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

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

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