OpenID 和 OAuth 的区别及第三方登录的安全隐患分析

标签: openid oauth 登录 | 发表时间:2014-03-14 03:09 | 作者:天梯梦
出处:http://www.iteye.com

不知道什么时候开始,我们已经习惯了点击“用XX帐号登录”或者 "Login with XX" 来访问网站,但是大多数人可能都不知道这背后涉及的事有多复杂。

 

OpenID 和OAuth 完全是为了两种不同的需求而生

OpenID 的目标是为了帮助网站确认一个用户的身份 OAuth 的目标是为了授权第三方在可控范围下访问用户资源

 

OpenID 是怎么认证用户的?

一个网站如果想要接入 OpenID 认证是非常简单的,不需要创建应用,不需要 App Key ,不需要 Secret ,只需要将用户导向 OpenID Provider 的 Entry 并带上 Callback ,用户只要同意提供信息,你就可以拿到这个用户的“唯一标识”。

请注意这里我使用了“唯一标识”这种说法,因为对于网站来说,OpenID Provider 提供的既不是用户的 UID ,也不是用户的 E-Mail ,比如 Google 在默认情况下提供的就是一个几十位长的字符串,这个字符串是随机生成的,第三方网站无法从中获得用户的任何私人信息。这么说可能很抽象,举个例子:

比如我用 Google 的 OpenID 服务登录 example.com , example.com 先把我导向 Google 的授权页面,我使用 Google 帐号 [email protected] 登录并同意后,页面跳回 example.comexample.com 拿到了我的“唯一标识”,这个唯一标识可能是 cd5f2126c2b2f97ca2d446e52c6ff4baea56fd4bcfcea30afcaaf6b73bcb04a1example.com 从这个字符串里无法获得任何 [email protected] 的个人信息(甚至连邮箱地址也不知道), example.com 只知道以后只要使用谷歌登录并返回 cd5f2126c2b2f97ca2d446e52c6ff4baea56fd4bcfcea30afcaaf6b73bcb04a1 这个标识符,那就是我在登录。

显而易见,OpenID 是专为登录认证而生,它使用简单,门槛很低,但是如果你想在认证过程中获得用户的其他信息(比如 E-Mail )就得多做一步了。

 

如何在 OpenID 认证的过程中获得用户的部分信息?

传统的 OpenID 是做不到这一点的,你只能拿到“唯一标识”。不过新版的 OpenID 引入了 " OpenID attribute exchange" 这个概念,这样第三方可以在用户的许可范围内获得用户的部分具体信息。

还是上面的例子,如果 example.com 告诉 Google ,我想知道这个用户的 E-Mail 地址,谷歌就会在授权页面告诉用户:“example.com 想要你的 E-Mail 地址”,这时如果用户点击同意, example.com 就能在回调请求中拿到 [email protected] 这个地址。

对于网站能拿到的信息,不同 Provider 有不同的规定,一般来说包括

aim, blog, country, dob (date of birth), email, fullname, gender, icq, image, jabber, language, msn, nickname, phone, postcode, skype, timezone, website, yahoo

等等。

 

那么,OAuth 又是怎么认证用户的?

与 OpenID 相比,网站想接入 OAuth 要稍微麻烦点,网站需要先创建应用,拿到 Key 和 Secret ,才能接入 Provider 。

OAuth 的授权过程并不是身份认证的过程,这一点需要特别清楚,网站走完OAuth 流程并拿到用户的授权 token 后还需要通过 token 调用相应的用户信息接口才能获得“唯一标识”,举个例子:

我想通过新浪微博登录 example.comexample.com 要先把我 redirect 到新浪微博的授权页面,我通过微博帐号登录并授权后,页面跳回 example.comexample.com 拿到我的访问 token 后还要再调用一个接口来获得我的新浪会员 UID ,这个 UID 就是新浪用户的“唯一标识”了。

可以看出,OAuth 相对于 OpenID 最大的区别就是,网站实际上是拿到了你的帐户访问权限继而确认你的身份,这是一个安全隐患,因为网站在拿到你的“唯一标识”的同时还拿到了一把你的账户的 “临时钥匙”。至于网站会不会拿这把钥匙“干坏事”,这个只有站长心里清楚。同时 OAuth 还比 OpenID 多了几个额外的请求步骤,登录所费时间一定是长于 OpenID 的。

大多数的网民是没有这种意识的,他们对“通过XX登录”的认证过程中的提示早已视而不见:

Weibo Login Prompt

有多少人真正注意过左边的文字?

Douban Login Prompt

豆瓣写的更清楚,XXX应用“希望操作你在豆瓣上的数据”而不是“希望使用你的豆瓣账号来登录XXX”

 

国内外主要服务商认证方式对比

提供商 认证方式 认证后网站获得的权限 安全程度
Google OpenID + OAuth 如果使用OpenID,网站无法获得任何额外权限(包括获得你的Google账户名称),如果使用OAuth,网站须明确说明需要访问哪些服务的权限并经过用户逐项同意
Facebook OAuth 默认授权情况下只能读取你的公开信息(不包含E-Mail地址),如果网站需要更高级权限需要明确声明并经过用户逐项同意
QQ空间 OAuth 默认授权情况下只能读取你的公开信息(不包含QQ号),如果网站需要更高级权限需要明确声明并经过用户逐项同意
新浪微博 OAuth 默认授权情况下可以获得你的所有信息(私信及身份证号、姓名等除外),并可以你的身份操作绝大多数微博功能
Windows Live OAuth 默认授权情况下只能读取你的“唯一标识”,如果网站需要更高级权限需要明确声明并经过用户逐项同意,默认情况下基本类似于OpenID
腾讯微博 OpenID + OAuth 如果使用OpenID,网站无法获得任何额外权限,如果使用OAuth,默认会获得用户所有操作的权限,除非应用明确声明只需要部分权限 使用OpenID时, 使用OAuth时,
搜狐微博 OAuth 默认授权情况下可以获得你的绝大多数信息,并可以你的身份操作绝大多数微博功能
网易微博 OAuth 默认授权情况下可以获得你的绝大多数信息,并可以你的身份操作绝大多数微博功能
百度 OAuth 默认授权情况下只能读取你的公开信息(UID、百度帐户名),如果网站需要更高级权限需要明确声明并经过用户逐项同意
人人 OAuth 默认授权情况下只能读取你的公开信息(UID、好友关系等),如果网站需要更高级权限需要明确声明并经过用户逐项同意
开心网 OAuth 默认授权情况下只能读取你的公开信息,如果网站需要更高级权限需要明确声明并经过用户逐项同意

 

总结

总体来说,国外的网站都比较正规,第三方网站几乎无法获得任何私人信息,而国内网站对个人信息的保护水平高低不齐,某些网站甚至没有任何保护,新浪微博等网站的“第三方接入”,用一句话来说,不管你敢不敢用,我反正是不敢用。

 

原文: https://www.idndx.com/2012/04/23/openid-vs-oauth-and-the-security-risk-of-oauth-login/

 

 

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [openid oauth 登录] 推荐:

OpenID 和 OAuth 的区别及第三方登录的安全隐患分析

- - 编程语言 - ITeye博客
不知道什么时候开始,我们已经习惯了点击“用XX帐号登录”或者 "Login with XX" 来访问网站,但是大多数人可能都不知道这背后涉及的事有多复杂. OpenID 和OAuth 完全是为了两种不同的需求而生. OpenID 的目标是为了帮助网站确认一个用户的身份 OAuth 的目标是为了授权第三方在可控范围下访问用户资源.

GitHub - casinthecloud/cas-pac4j-oauth-demo: Demo webapps to test CAS/OAuth/OpenID/SAML client support and OAuth server support in CAS version >= 4.0.0

- -

PHP实现Google Oauth的登录系统

- - 极客521 | 极客521
本文讲述的是如何为你的PHP项目实现Google的Oauth系统. 这个示例PHP脚本非常快,对增加你的PHP项目注册当然是很有帮助的. 在这之前,我们已经覆盖了包含Facebook、Twitter、Google plus以及Instagram的Oauth登录系统示例. 很遗憾之前我遗漏掉了Google的Oauth登录系统.

如何通过 OAuth 2.0 使 iOS Apps 集成 LinkedIn 登录功能?

- - OneAPM 博客
社交网络早已成为人们日常生活的一部分. 其实,社交网络也是编程生活的一部分,大多数 App 必须通过某种方式与社交网络交互,传送或接收与用户相关的数据. 大多数情况下,用户需要登录某种社交网络,授权 App 代表自己进行请求. 目前,此类社交网络的种类非常丰富,以 Facebook 与 Twitter 最为常用.

OAuth的改变

- lyxint - 火丁笔记
去年我写过一篇《OAuth那些事儿》,对OAuth做了一些简单扼要的介绍,今天我打算写一些细节,以阐明OAuth如何从1.0改变成1.0a,继而改变成2.0的. 在OAuth诞生前,Web安全方面的标准协议只有OpenID,不过它关注的是验证,即WHO的问题,而不是授权,即WHAT的问题. 好在FlickrAuth和GoogleAuthSub等私有协议在授权方面做了不少有益的尝试,从而为OAuth的诞生奠定了基础.

理解OAuth 2.0

- - 阮一峰的网络日志
OAuth是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用,目前的版本是2.0版. 本文对OAuth 2.0的设计思路和运行流程,做一个简明通俗的解释,主要参考材料为 RFC 6749. 为了理解OAuth的适用场合,让我举一个假设的例子. 有一个"云冲印"的网站,可以将用户储存在Google的照片,冲印出来.

oauth 认证心得

- 非狐外传 - python.cn(jobs, news)
OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准. 简易来说,就是我们可以在某一个第三方服务器,如:新浪,豆瓣,在用户授权,并且不透漏密码等信息给我们的条件下,访问和修改用户的资源. oauth的项目主页为:http://oauth.net/ ,现在国内很多网站的开放平台都采用了Oauth方式来进行授权.

OAuth学习笔记

- 宋大妈 - FeedzShare
来自: 标点符 - FeedzShare  . 发布时间:2011年08月29日,  已有 2 人推荐. OAuth(开放授权)是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而无需将用户名和密码提供给第三方应用. OAuth允许用户提供一个令牌,而不是用户名和密码来访问他们存放在特定服务提供者的数据.

OAuth 2.0 工作流程

- - 企业架构 - ITeye博客
原文链接:http://www-01.ibm.com/support/knowledgecenter/SSELE6_8.0.0.3/com.ibm.ammob.doc_8.0.0.3/config/concept/con_oauth20_workflow.html%23con_oauth20_workflow?lang=zh.