我真的在试图理解OpenID和OAuth之间的区别?也许它们是完全不同的两件事?
当前回答
很多人仍然访问这个网站,这里有一个非常简单的图表来解释它
礼貌维基百科
其他回答
OpenId -仅用于身份验证。
OAuth—用于身份验证和授权。授权依赖于access_token,它是JWT令牌的一部分。它可以包含用户权限的详细信息或任何有用的信息。
两者都可以依赖第三方认证提供商来维护他们的帐户。例如,OKTA身份提供者,User在OKTA登录页面上提供凭据,在成功登录时,用户被重定向到消费者应用程序,头部有JWT令牌。
OpenID(主要)用于识别/身份验证,这样stackoverflow.com就知道我拥有chris.boyle.name(或任何位置),因此我可能就是昨天拥有chris.boyle.name并获得一些声誉点的同一个人。
OAuth是为授权代表您执行操作而设计的,因此stackoverflow.com(或任何地方)可以请求许可,例如,自动代表您发送Tweet,而不需要知道您的Twitter密码。
OAuth
仅用于委托授权——这意味着您授权第三方服务访问使用个人数据,而无需提供密码。此外,OAuth“会话”通常比用户会话存活更久。这意味着OAuth被设计为允许授权
例如,Flickr使用OAuth允许第三方服务发布和编辑个人照片,而不需要他们提供自己的flicker用户名和密码。
OpenID
用于验证单点登录身份。所有OpenID应该做的就是允许OpenID提供者证明你说你是。然而,许多站点使用身份验证来提供授权(然而,这两者可以分开)
也就是说,一个人在机场出示护照,以证明他们所使用的机票上的人就是他们自己。
我目前正在研究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视为具有作用域的授权。