我真的想了解OpenID和OAuth之间的区别？也许它们是两个完全不同的东西？

OpenID是关于身份验证(即证明您是谁)，OAuth是关于授权(即授予对功能/数据的访问权限)的。无需处理原始身份验证)。

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

"从用户的角度看OpenID和OAuth"这篇博文从用户的角度对两者进行了简单的比较，"OAuth OpenID:如果你认为它们是相同的，那你就找错树了"这篇博文有更多关于它的信息。

比较OAuth和OpenID有三种方法：

1。目的

OpenID是为联邦身份验证创建的，也就是说，让第三方通过使用他们已经拥有的帐号为您验证用户。联邦中的术语是关键的，因为OpenID的整个点是可以使用任何提供者(除了白名单之外)。您不需要预先选择或协商与供应商的交易，允许用户使用他们拥有的任何其他帐户。

OAuthe是为了消除用户与第三方应用程序共享密码的需要而创建的。它实际上是一种解决OpenID问题的方法：如果你支持你的网站上的OpenID，你就不能使用HTTP基本凭据(用户名和密码)来提供API，因为用户在你的网站上没有密码。

问题在于，这两种协议分离了用于身份验证的OpenID和用于授权的OAuth，这两种协议可以完成许多相同的事情。它们各自提供了一组不同的特性，这些特性是不同实现所需要的，但本质上，它们是非常可互换的。在其核心，这两个协议都是断言验证方法(openid仅限于"这就是我"断言，而oauth提供了一个"访问令牌"，可以通过API交换任何支持的断言)。

2。特征

这两种协议都为站点提供了将用户重定向到其他地方并返回可验证断言的方法。OpenID提供了一个身份断言，而OAuth更为通用，其形式是访问令牌，然后可用于"询问OAuth提供程序问题"。但是，它们都支持不同的功能：

OpenID-OpenID最重要的特性是它的发现过程。OpenID不需要对每个您想提前使用的提供者进行硬编码。使用Discovery，用户可以选择他们想要认证的任何第三方提供者。这个发现功能也导致了OpenID的大部分问题，因为它的实现方式是使用HTTP URI作为大多数Web用户无法获得的标识符。openid的其他功能是支持使用dh交换的即席客户端注册、优化最终用户体验的即时模式，以及在不与提供者进行另一次往返的情况下验证断言的方法。

OAuth——OAuth最重要的特性是访问令牌，它提供了一种持久的方法来发出额外的请求。与OpenID不同，OAuth不以身份验证结束，而是提供一个访问令牌来访问由同一第三方服务提供的其他资源。但是，由于OAuth不支持发现，因此需要预先选择并对您决定使用的提供者进行硬编码。访问您网站的用户不能使用任何标识符，只能使用您预先选择的标识符。另外，OAuth没有标识概念，因此将其用于登录意味着要么添加自定义参数(通过Twitter完成)，要么进行另一个API调用以获取当前的"登录"用户。

三。技术实施

这两个协议在使用重定向获得用户授权时共享一个公共体系结构。在OAuth中，用户授权访问其受保护的资源以及在OpenID中访问其标识。但这就是他们所分享的。

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

openid主要用于身份识别/认证，所以stackoverflow.com知道我拥有chris.boyle.name(或任何地方)，因此我可能是昨天拥有chris.boyle.name的人，并获得了一些声誉点。

OAuth是为授权代表您采取行动而设计的，因此stackoverflow.com或任何地方都可以在不知道您的Twitter密码的情况下，自动请求允许(例如)代表您推特。

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

维基百科

奥瑙

仅用于委托authorization--表示您授权第三方服务访问使用个人数据，而不提供密码。此外，OAuth"会话"通常比用户会话寿命长。这意味着OAuth的设计允许授权

也就是说，Flickr使用OAuth允许第三方服务代表他们发布和编辑个人图片，而不必给出闪烁用户名和密码。

OpenID

用于authenticate单点登录标识。OpenID应该做的就是允许OpenID提供者证明你说的是。然而，许多站点使用身份验证来提供授权(但是可以将两者分开)

也就是说，在机场出示他们的护照，以验证(或证明)他们使用的机票上的人是谁。

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

OpenID和OAuth都是基于HTTP的身份验证和/或授权协议。这两种方法都允许用户在不向客户端或第三方提供身份验证凭据或覆盖权限的情况下执行操作。虽然它们很相似，并且有建议的标准可以同时使用它们，但是它们是独立的协议。

OpenID用于联合身份验证。客户机接受来自任何提供程序的身份声明(尽管客户机可以自由使用白名单或黑名单提供程序)。

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

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

我相信重新审视这个问题是有意义的，正如评论中指出的那样，引入OpenID Connect可能会带来更多的混乱。

OpenID Connect是一种身份验证协议，类似于OpenID 1.0/2.0，但它实际上是在OAuth 2.0之上构建的，因此您将获得授权功能以及身份验证功能。这篇文章(相对较新，但很重要)详细解释了这两者之间的区别：http://oauth.net/articles/authentication/

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.

(源)

How is OpenID Connect different than OpenID 2.0?

OpenID Connect performs many of the same tasks as OpenID 2.0, but does
so in a way that is API-friendly, and usable by native and mobile
applications. OpenID Connect defines optional mechanisms for robust
signing and encryption. Whereas integration of OAuth 1.0a and OpenID
2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.

(源)

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.

(源)

谷歌的OAuth2.0

Google's OAuth 2.0 APIs can be used for both authentication and
authorization. This document describes our OAuth 2.0 implementation
for authentication, which conforms to the OpenID Connect
specification, and is OpenID Certified. The documentation found in
Using OAuth 2.0 to Access Google APIs also applies to this service. If
you want to explore this protocol interactively, we recommend the
Google OAuth 2.0 Playground.

(源)

与其说是答案，不如说是问题的延伸，但它可能会为上述伟大的技术答案增加一些视角。我是一个经验丰富的程序员，在很多领域，但一个完全的noob到网络编程。现在尝试使用Zend框架构建基于Web的应用程序。

肯定会实现一个特定于应用程序的基本用户名/密码认证界面，但要认识到，对于越来越多的用户来说，另一个用户名和密码的想法是一种威慑。虽然不完全是社交网络，但我知道应用程序的大部分潜在用户已经拥有Facebook或Twitter帐户。应用程序并不真的想要或者需要从这些站点访问关于用户帐户的信息，它只是想提供不需要用户设置新帐户凭据的便利，如果他们不想这样做的话。从功能的角度来看，这似乎是OpenID的海报孩子。但似乎脸谱网和Twitter都不是OpenID提供商，尽管它们确实支持OAuthAudio认证来访问他们的用户数据。

在我读过的所有关于这两者的文章中，以及它们的不同之处，直到我看到卡尔·安德森在上面的观察，"OAuth可以用于认证，这可以被认为是一种禁止操作的授权"，我看到了任何明确的确认，即OAuth足以满足我想要做的事情。

事实上，当我把这个"答案"贴出来的时候，我当时不是会员，我在这一页的底部仔细地看了很久，找到了识别我自己的选项。如果我没有openid登录，可以选择使用openid登录或者获取一个，但是Twitter和Facebook没有，这似乎表明OAuth不适合这个工作。但后来我打开了另一个窗口，寻找StackOverflow的一般注册流程——瞧，有很多第三方认证选项，包括Facebook和Twitter。最后，我决定使用我的Google ID(这是一个OpenID)，正是因为我不想允许StackOverflow访问我的朋友列表以及Facebook喜欢分享的关于其用户的任何内容——但至少这是一个证据，证明OAuth足以满足我的使用需求。

如果有人可以发布信息或指向支持这种多第三方授权设置的信息，以及如何处理撤销授权或失去对第三方网站访问权限的用户，那将是非常棒的。我还觉得我在这里的用户名标识了一个唯一的stackoverflow帐户，如果我想设置它，我可以通过基本身份验证访问它，还可以通过其他第三方身份验证程序访问这个帐户(例如，如果我登录到任何Google、Facebook或叽叽喳喳……)因为这个网站正在做这件事，所以这里的一些人可能对这个问题有很好的了解。-)

不好意思，这么长时间以来，这只是一个问题，而不是一个答案——但是卡尔的评论让它看起来是在OAuth和OpenID上大量线程中发布的最合适的地方。如果有一个更好的地方我没有找到，我事先道歉，我确实尝试了。

• OpenID是开放标准和分散认证协议，由OpenID基金会控制。
• OAuth是访问委派的开放标准。
• openid connect(oidc)结合了openid和oauth的特性，即同时进行身份验证和授权。

openid采用由某些"openid provider"即标识提供者(idp)管理的唯一URI的形式。

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

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

例如，如果您选择使用您的Google帐户登录Auth0，那么您使用的是OIDC。一旦您成功地通过谷歌认证并授权Auth0访问您的信息，谷歌将向Auth0发送有关用户和所执行认证的信息。此信息在JSON Web令牌(JWT)中返回。您将收到一个访问令牌，如果需要，还将收到一个ID令牌。令牌类型：源：openid connect

类比：组织使用身份证进行身份识别，并且包含芯片，它存储员工的详细信息以及授权，即校园/大门/ODC访问。身份证作为OIDC，芯片作为OAuth。更多示例和表单wiki

OpenID证明了你是谁。

OAuth授权访问授权方提供的功能。

我目前正在研究OAuth 2.0和OpenID Connect规范。下面是我的理解：早些时候他们是：

技术上来说，这里已经给出了很好的答案，我想给出一个简单的进化观点。

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

通过定义认证回答两个问题。

OAuth 2.0具有以下授予类型

• 客户机凭据：当一个应用程序需要与另一个应用程序交互并修改多个用户的数据时。
• 授权代码：用户委托授权服务器颁发客户端可以用来访问受保护资源的访问令牌
• 刷新令牌：当访问令牌过期时，可以利用刷新令牌获取新的访问令牌
• 密码：用户向调用授权服务器并接收访问令牌的客户端提供登录凭据

所有4个都有一个共同点，access_token，一个可以用来访问受保护资源的工件。

访问令牌没有提供"身份验证"协议必须回答的2个问题的答案。

解释OAuth2.0的示例(学分：OAuth2实际操作，曼宁出版物)

我们来谈谈巧克力吧。我们可以用巧克力做许多糖果，包括软糖、冰淇淋和蛋糕。但是，这些都不能等同于巧克力，因为制作糖果需要多种其他成分，如奶油和面包，尽管巧克力听起来像是主要成分。同样，OAuth2.0是巧克力，而cookie、tls基础结构、身份提供者是提供"身份验证"功能所需的其他成分。

如果您想要认证，您可以使用OpenID Connect，它除了提供一个访问令牌之外，还提供一个"ID_令牌"，它可以回答每个认证协议必须回答的问题。

OpenID使用OAuth处理身份验证。

与此类似，它就像.NET依赖Windows API一样。您可以直接调用WindowsAPI，但它非常广泛、复杂，方法参数也非常庞大，很容易出错/出错/安全问题。

与openid/oauth相同。OpenID依赖OAuth来管理身份验证，但定义了特定的令牌(ID_令牌)、数字签名和特定的流。

我想讨论这个问题的一个特殊方面，如本评论所述：

OAuth: before granting access to some feature, authentication must be done, right ?. so OAuth = what OpenId does + grants access to some features ? – Hassan Makarov Jun 21 at 1:57

对。。。不，答案很微妙，所以请容忍我。

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

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

别犯这个错误。

虽然您通过OAuth提供者的身份验证(例如，通过用户名和密码，或者SSL客户机证书，或者其他方式)是正确的，但是客户机得到的回报不一定被视为身份证明。一个例子是一个流程，在这个流程中，对另一个用户的资源的访问被委托给您(以及通过代理，OAuth客户机)。授权并不意味着认证。

为了处理身份验证，您可能需要查看OpenID连接，它本质上是由OAuth- 2设置的基础之上的另一层。这是一个引用，它捕获了(在我看来)有关OpenID连接的最突出点(来自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: [...]

然后，文档继续描述(除其他外)令牌ID和一个userinfo端点。前者提供了一组声明(您是谁，颁发令牌的时间等，可能还有一个签名，通过已发布的公钥验证令牌的真实性，而无需请求上游服务)，后者提供了一种方法，例如请求用户的名/姓、电子邮件和类似的信息位，所有这些都是标准的。ZedWay(与人们在OpenID连接标准化事物之前使用的对OAuth的特殊扩展相反)。

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

OAuth是一种协议，旨在验证最终用户的身份并向第三方授予权限。这个验证会产生一个令牌。第三方可以使用此令牌代表用户访问资源。令牌有一个作用域。作用域用于验证用户是否可以访问资源

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

OAuth在授权的基础上构建身份验证：用户将对其身份的访问权委托给应用程序，应用程序随后成为身份API的使用者，从而首先查明是谁授权了客户机http://oauth.net/articles/authentication/