假设有两家互联网企业 A 和 B，其中 B 是一家提供相片云存储的公司。即 B 的用户可以把相片上传到 B 网站上长期保存，然后可以在不同的设备上查看。某一天，A 和 B 谈成了一项合作：希望 B 用户在使用 A 的客户端时，也可以观看他在 B 的相片。假设你是技术负责人，需要出一个实现方案，怎么做？
要不让 B 提供一个接口：
http://xxx.xxx.com/getPhoto?account=
参数：
account ：B 账号
返回：
指定账号下的所有相片
有了这个接口，A 的客户端只需在界面上显示一个输入框，让用户输入他的 B 账号，然后调用这个接口来获取相片就可以了。
这样可行吗？
NO！为啥？
因为实现并开放这样一个接口，相当于直接把 B 公司的相片资源全部暴露在互联网中，虽然并没有公开，但是对于有点安全意识的技术人员来说，要发现这个接口简直轻而易举。这样的话，B 的用户就没有任何隐私了。
那怎么办呢？这样吧，为了保证不能随便获取别人的相片，我们把接口改成这样：
http://xxx.xxx.com/getPhoto?account=&pwd=
要求A在调用接口之前，先弹出输入框，让用户输入账号密码，然后传给B。B验证账号密码通过，就返回该账号下的所有相片。这样，即使黑客发现了这个接口，他不知道用户的密码，所以没办法窃取用户的相片了。这样 OK 了吧？
可能对于很多从没有接触过 Oauth 协议的人来说，这样说就已经没什么问题了。但是，实际上答案还是 NO！绝不可以这么做！
为什么？这里涉及到一个信任问题。如果这样实现，那么，用户必须在 A 的软件里输入他在 B 的账号和密码。如果你是一个隐私意识很强的人，你很可能会问：“凭什么我要把 B 的账号密码告诉 A ？”这里，从用户的角度就已经感受到一种不安全感，凭什么让我信任你 A，你保证不拿我的 B 账号密码去干坏事？而更深一层次，站在 B 的角度来考虑的话，也是一样的问题：我凭什么绝对信任 A？万一 A 在这个过程偷偷把账号密码存起来了呢？那随着时间的推移，A 就慢慢地搜集到一大批 B 的账号密码！这对 B 来讲，是不能接受的！
那怎么办呢？
我们分析一下这个问题产生的原因，主要是在于 A、B、用户 三方的交互模型有问题。请看：
在这个场景下，用户需要访问他在 B 的相片资源，但是他不能直接和 B 打交道，而是必须通过 A。在这个前提下去考虑问题，无论如何无法想出一个既能实现功能，又能让用户和 B 都感到放心的实现方案。
Oauth2.0 就是为了解决这个问题而提出来的交互模型。它告诉人们，在这种场景下，三方要怎么打交道，才能做到安全、合理。
具体来说，Oauth2.0 的交互模型的核心是这个样子的：
解释一下几个术语。
资源服务器。即资源的存放地点，或者说资源的访问入口。在例子中，资源服务器即 getPhoto 接口所部署的服务器。A必须经由这里去访问资源。
鉴权服务器。这是一个对用户的身份进行认证、并对客户端进行授权的地方。这也是在Oauth2.0协议新增的一个节点。通常情况下，鉴权服务器也是属于 B 公司的。
好，接下来看看整个交互过程是怎样的。
首先，同样是 B 的用户在使用 A 的软件，然后，A 需要访问 B 用户的相片。这个时候，A 并不是展示一个输入框给用户，而是打开一个页面。这个页面就是 B 部署在鉴权服务器上面的一个鉴权页面，通常情况下，它长得类似下面这个样子：
上面这个是腾讯给有道云笔记进行授权的页面。（是不是很熟悉？在哪见过？有兴趣了解一下账号接出的原理，其实就是Oauth2.0。）
这个页面有两个要素：
1，有认证机制。在腾讯这个例子中，你需要输入QQ账号密码，证明你是一个合法的QQ用户
2，展示了授权信息。看页面右方“有道云笔记将获得以下权限”部分。这是在告诉用户，如果你授权给客户端，那么，客户端将获得访问你这些资源的权限
注意，这个页面是部署在 B 的鉴权服务器上，所有用户输入的账号密码是直接提交给 B，A 是没有任何机会拿到的。
如果用户同意授权并且认证通过，那么，接下来鉴权服务器会通知 A，并给 A 发送一个访问令牌（access token）。有了这个访问令牌，A 就可以拿着它去找 资源服务器要资源了。
所以，获取相片的接口会是类似这个形式：
http://xxx.xxx.com/getPhoto?accesstoken=
资源服务器在接收到这个请求之后，会拿着 access token，再去找鉴权服务器，检查这个 access token 的合法性和权限，如果通过的话，才返回资源给A。
这样就确保了整个流程是相对安全的。Oauth2.0 就是为了这种使用场景而设计的。
更多技术文章，请关注个人号：
