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

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

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

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

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

礼貌维基百科

在阅读和做了一些工作后，我认为我需要知道的事情是: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视为具有作用域的授权。