在上一篇文章《Oauth2.0（一）：为什么需要 Oauth2.0 协议？》中，提到Oauth2.0的交互模型如下：
这个模型涉及到三方：资源拥有者（用户）、应用方（A）、服务提供方（B）。其中，服务提供方包含两个角色：鉴权服务器和资源服务器。鉴权服务器负责对用户进行认证，并授权给应用方权限。认证这一步好实现，无非就是验一下账号密码。但是授权这一步怎么做？这里参考QQ授权给有道的页面：
可以看到在QQ的授权页面上，有”有道云笔记将获得以下权限“的字样以及权限信息。鉴权服务器需要知道请求授权的应用方的身份以及该应用方请求的权限。所以，需要在谈完合作之后，为每一个应用方预先分配一个 id，并给每个 id 对应一个名称以及权限信息。这些信息可以保存在鉴权服务器上。然后，应用方每次打开鉴权页面的时候，把属于自己的 id 传过来，像这样：
http://xxx.xxx.com/oauthPage?client_id=xxx
鉴权服务器就可以根据这个 id 去展示授权信息了。
这个流程是 ok 的。但是，随着时间的推移和业务的增长，会发现，修改配置的工作消耗了太多的人力。有没有办法把这个过程自动化起来，把人工从这些繁琐的操作中解放出来？当开始考虑这一步，开放平台的成型也就是水到渠成的事情了。
开放平台是由 Oauth2.0 协议衍生出来的一个产品。它的作用是让应用方自己去这上面进行注册、申请，通过之后系统自动分配 client_id ，并保存进数据库。
开放平台的一个实例：http://open.weibo.com/
应用方要完成申请，通常需要填写应用方程序的类型（web、移动端app等）、企业介绍、执照、想要获取的权限等等信息。这些信息在得到服务提供方的人工审核通过后，开发平台就会自动分配一个 client_id 给应用方了。
到这里，已经实现了登录认证、鉴权页的信息展示。那么接下来，当用户成功进行授权之后，鉴权服务器需要把产生的 access token 发送给应用方。这一步，怎么做？
方案是这样的：让应用方在开放平台申请的时候，填写一个 url，例如：
http://www.abc.com
然后。每次当有用户授权成功之后，鉴权服务器将页面重定向到这个 url ，并带上 access token。这一步叫做回调。例如：
http://www.abc.com?accesstoken=xxxxxxxx
这样，应用方就接收到了这个 access token，而且鉴权服务器的授权动作已经完成，刚好可以把程序的控制权转交回应用方，由应用方决定接下来向用户展示什么内容。
更多技术文章，请关注个人号：
