我目前正在研究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连接是最相关的，所以我将解释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视为具有作用域的授权。

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

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

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

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

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

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

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

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

礼貌维基百科