我真的在试图理解OpenID和OAuth之间的区别?也许它们是完全不同的两件事?
当前回答
很多人仍然访问这个网站,这里有一个非常简单的图表来解释它
礼貌维基百科
其他回答
OpenId使用OAuth来处理身份验证。
通过类比,就像。net依赖于Windows API。你可以直接调用Windows API,但是它太宽了,太复杂了,方法参数太大了,你很容易犯错误/bug /安全问题。
OpenId/OAuth也是如此。OpenId依赖于OAuth来管理身份验证,但定义了特定的令牌(Id_token)、数字签名和特定的流。
在阅读和做了一些工作后,我认为我需要知道的事情是: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(主要)用于识别/身份验证,这样stackoverflow.com就知道我拥有chris.boyle.name(或任何位置),因此我可能就是昨天拥有chris.boyle.name并获得一些声誉点的同一个人。
OAuth是为授权代表您执行操作而设计的,因此stackoverflow.com(或任何地方)可以请求许可,例如,自动代表您发送Tweet,而不需要知道您的Twitter密码。
我目前正在研究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)
从技术上讲,这里已经给出了很好的答案,我想到了给出简要的进化观点
OAuth
仅用于委托授权——这意味着您授权第三方服务访问使用个人数据,而无需提供密码。此外,OAuth“会话”通常比用户会话存活更久。这意味着OAuth被设计为允许授权
例如,Flickr使用OAuth允许第三方服务发布和编辑个人照片,而不需要他们提供自己的flicker用户名和密码。
OpenID
用于验证单点登录身份。所有OpenID应该做的就是允许OpenID提供者证明你说你是。然而,许多站点使用身份验证来提供授权(然而,这两者可以分开)
也就是说,一个人在机场出示护照,以证明他们所使用的机票上的人就是他们自己。