简单介绍 Oauth2.0 原理

  有两家互联网企业 A 和 B,其中 B 是一家提供相片云存储的公司。用户可以把相片上传到 B 网站上长期保存,然后可以在不同的设备上查看。某一天,A 和 B 谈成了一项合作:希望用户在使用 A 的客户端时,也可以观看他在 B 的相片。这个技术上要怎么实现呢?

  选项一:由 B 提供一个接口:

 

  GET /photos?account=

  参数:

    account : B 账号

  返回:

    指定账号下的所有相片

 

  有了这个接口,A 的客户端只需在界面上显示一个输入框,让用户输入他的 B 账号,然后调用这个接口来获取相片就可以了。

  这样可行吗?

  NO!为啥?

  因为实现并开放这样一个接口,相当于直接把 B 公司的相片资源全部暴露在互联网中,虽然并没有公开,但是对于有点安全意识的技术人员来说,要发现这个接口简直轻而易举。这样的话,B 的用户就没有任何隐私了。

  那怎么办呢?这样吧,为了保证不能随便获取别人的相片,我们把接口改成这样:

 

  GET /photos?account=&pwd=

 

  除了要求用户输入账号,还要输入密码。只有当账号密码验证通过,才返回该账号下的所有相片。这样,即使黑客发现了这个接口,他不知道用户的密码,所以没办法窃取用户的相片了。这样 OK 了吧?

  答案还是 NO!绝不可以这么做!

  为什么?这里涉及到一个信任问题。如果这样实现,那么,用户必须在 A 的软件里输入他在 B 的账号和密码。如果你是一个隐私意识很强的人,你很可能会问:“凭什么我要把 B 的账号密码告诉 A ?”这里,从用户的角度就已经感受到一种不安全感,凭什么让我信任你 A,你保证不拿我的 B 账号密码去干坏事?而更深一层次,站在 B 的角度来考虑的话,也是一样的问题:我凭什么绝对信任 A?如果 A 在接收到用户的输入之后,马上就把请求发到我们这里来,那是 ok 的。但是万一 A 在这个过程偷偷把账号密码存起来了呢?那随着时间的推移,A 就慢慢地搜集到一大批 B 的账号密码!这对 B 来讲,是不能接受的!

  那怎么办呢?

  我们分析一下这个问题产生的原因,主要是在于 A、B、用户 三方的交互模型有问题。请看:

  在这个场景下,用户需要访问他在 B 的相片资源,但是他不能直接和 B 打交道,而是必须通过 A。在这个前提下去考虑问题,无论如何无法想出一个既能实现功能,又能让用户和 B 都感到放心的实现方案。

  Oauth2.0 就是为了解决这个问题而提出来的交互模型。它告诉人们,在这种场景下,三方要怎么打交道,才能做到安全、合理。

  具体来说,Oauth2.0 的交互模型的核心是这个样子的:

  解释一下几个术语。

  资源服务器。即资源的存放地点,或者说资源的访问入口。在例子中,资源服务器即 getPhoto 接口所部署的服务器。客户端必须经由这里去访问资源。

  鉴权服务器。这是一个对用户的身份进行认证、并对客户端进行授权的地方。这也是 Oauth2.0 的关键节点。通常情况下,鉴权服务器也是属于 B 公司的。

 

  好,接下来看看整个交互过程是怎样的。

  首先,同样是 B 的用户在使用 A 的软件,然后,A 需要访问 B 用户的相片。这个时候,A 并不是展示一个输入框给用户,而是打开一个页面。这个页面就是 B 部署在鉴权服务器上面的一个鉴权页面,通常情况下,它长得类似下面这个样子:

  上面这个是腾讯给有道云笔记进行授权的页面。(是不是很熟悉?在哪见过?有兴趣了解一下账号接出的原理,其实就是Oauth2.0。)

  这个页面有两个要素:

  1,有认证机制。在腾讯这个例子中,你需要输入QQ账号密码,证明你是一个合法的QQ用户

  2,展示了授权信息。看页面右方“有道云笔记将获得以下权限”部分。这是在告诉用户,如果你授权给客户端,那么,客户端将获得访问你这些资源的权限

  注意,这个页面是部署在 B 的鉴权服务器上,所有用户输入的账号密码是直接提交给 B,A 是没有任何机会拿到的。

  如果用户同意授权并且认证通过,那么,接下来鉴权服务器会通知 A,并给 A 发送一个访问令牌(access token,其实就是一段全局唯一的随机字符串)。有了这个访问令牌,A 就可以拿着它去找资源服务器要资源了。

  所以,获取相片的接口会是类似这个形式:

 

  GET /photos?accesstoken=

 

  资源服务器在接收到这个请求之后,会拿着 access token,再去找鉴权服务器,检查这个 access token 的合法性和权限,如果通过的话,才返回资源给客户端。

 

  如此,即实现了功能,也保障了安全性。不过你可能会问,这个 access token 和账号密码的区别是什么呢?都是代表用户身份的,为什么 access token 就更安全?答案是:

  1,账号密码是一切,有了账号密码就几乎可以做任何事情(甚至改掉原密码)。而 access token 是有限制范围的。每个 access token 都有一个 scope,也就是允许执行哪些操作。

  2,access token 是有有效期的。如果 access token 被窃取,也不能一直用。

 

       若有疑问,可以直接评论。

 

posted @ 2015-05-22 21:46  尹三黎  阅读(7876)  评论(1编辑  收藏