OpenID(主要)用于识别/身份验证，这样stackoverflow.com就知道我拥有chris.boyle.name(或任何位置)，因此我可能就是昨天拥有chris.boyle.name并获得一些声誉点的同一个人。

OAuth是为授权代表您执行操作而设计的，因此stackoverflow.com(或任何地方)可以请求许可，例如，自动代表您发送Tweet，而不需要知道您的Twitter密码。

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

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

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

OAuth

仅用于委托授权——这意味着您授权第三方服务访问使用个人数据，而无需提供密码。此外，OAuth“会话”通常比用户会话存活更久。这意味着OAuth被设计为允许授权

例如，Flickr使用OAuth允许第三方服务发布和编辑个人照片，而不需要他们提供自己的flicker用户名和密码。

OpenID

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

也就是说，一个人在机场出示护照，以证明他们所使用的机票上的人就是他们自己。

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

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

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

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

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

有三种方法可以比较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中，用户授权访问他们的身份。但这就是他们所有的共同点。

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

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

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

礼貌维基百科

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

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

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

OpenID证明你是谁。

OAuth授予对授权方提供的特性的访问权。

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游乐场。

(源)

我目前正在研究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来处理身份验证。

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

OpenId/OAuth也是如此。OpenId依赖于OAuth来管理身份验证，但定义了特定的令牌(Id_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).

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

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

OAuth是一种用于验证终端用户身份并向第三方授予权限的协议。这个验证的结果是一个令牌。第三方可以使用这个令牌来代表用户访问资源。令牌有一个作用域。作用域用于验证用户是否可以访问某个资源

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

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返回访问令牌，用于从资源服务器访问资源，OpenID返回JWT /加密令牌中关于资源的元数据细节

OpenId -仅用于身份验证。

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

两者都可以依赖第三方认证提供商来维护他们的帐户。例如，OKTA身份提供者，User在OKTA登录页面上提供凭据，在成功登录时，用户被重定向到消费者应用程序，头部有JWT令牌。

在阅读和做了一些工作后，我认为我需要知道的事情是:OpenID Connect, OAuth, JWT和SAML。

我来总结一下，可能会对大家有所帮助:

OpenID连接(OIDC):如果我们可以使用谷歌帐户登录一个网站，那么您使用的是OIDC。

OAuth:一个应用程序想要访问我的facebook联系人列表，并代表我做一些事情。如果我授权这个应用程序，那么我可能正在使用OAuth。

JWT: OAuth使用JWT, JWT (JSON Web令牌)-它只是一种令牌格式。JWT令牌是JSON编码的数据结构，包含有关发行者、主题(索赔)、到期时间等信息。对它进行签名以防止篡改和真实性，并且可以使用对称或非对称方法对它进行加密以保护令牌信息。JWT比SAML 1.1/2.0更简单，所有设备都支持它，而且它比SWT(简单Web令牌)更强大。

OAuth中的授权流程:

OAuth 2.0协议为授权用户和获取访问令牌提供了几个工作流。这取决于客户端的类型和体系结构，哪个流是最合适的。

下面是2个最常用的授权流程:

授权码:适用于包含客户端和服务器组件的第三方网站。

用户向安全登录网页输入凭据。 登录后，浏览器被重定向到一个特殊的URL(由客户端定义)，并在URL中传递一个授权代码。 第三方服务器使用授权代码在后台通过另一个HTTP请求获取访问令牌。 从https://developers.video.ibm.com/api-basics-authentication/

注意:如果你有一个前端应用程序，服务器在浏览器中设置了cookie，那么你的浏览器中已经有了cookie，可以访问该网站。

客户端凭证:开发服务器端应用程序以管理其内容或设置的用户的最佳选择。

IBM有一个很好的指南:https://developers.video.ibm.com/api-basics-authentication 要了解所有其他流的优点和缺点:这里:https://www.geeksforgeeks.org/workflow-of-oauth-2-0/

SAML:也用作openid的替代品，但它是基于xml的。因为开发人员发现OIDC更容易使用，而且它更灵活(例如，与基于xml的SAML相比，与移动应用程序一起使用更容易)，OIDC看起来将成为赢家。

OpenID连接(OIDC)与SAML:主要区别:

SAML transmits user data in XML format. OIDC transmits user data in JSON format. SAML calls the user data it sends a SAML Assertion. OIDC calls the data Claims. SAML calls the application or system the user is trying to get into the Service Provider. OIDC calls it the Relying Party. SAML is old, has more features, but OpenID is gaining more popularity as it is easier to implement, easier to use than XML based SAML But not all identity providers support OpenID or SAML, if the identity provider you want to integrate only supports SAML, then you have no choice.

想要更多OpenID vs SAML?读下面: https://www.onelogin.com/blog/real-difference-saml-oidc https://auth0.com/intro-to-iam/saml-vs-openid-connect-oidc/

想要更多吗?你可以读一下OAuth和OpenID的类比: http://cakebaker.42dh.com/2008/04/01/openid-versus-oauth-from-the-users-perspective/

现在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视为具有作用域的授权。