更多的是对问题的延伸而不是答案，但它可能会为上面伟大的技术答案增加一些视角。我是一个在很多领域都很有经验的程序员，但是在网页编程方面完全是个新手。现在尝试使用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、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 -仅用于身份验证。

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

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

更多的是对问题的延伸而不是答案，但它可能会为上面伟大的技术答案增加一些视角。我是一个在很多领域都很有经验的程序员，但是在网页编程方面完全是个新手。现在尝试使用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在授权之上构建身份验证:用户将对其身份的访问委托给应用程序，然后应用程序成为身份API的消费者，从而找出是谁首先授权了客户端http://oauth.net/articles/authentication/

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