Oauth2.0（二）：开放平台

　　上一节说到Oauth2.0 的交互模型。模型涉及到三方：资源拥有者、客户端、服务提供方。其中，服务提供方包含两个角色：鉴权服务器和资源服务器。鉴权服务器负责对用户进行认证，并受权给客户端权限。认证这一步好实现，无非就是验一下帐号密码。可是受权这一步怎么作？能够看到在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，并且鉴权服务器的受权动做已经完成，恰好能够把程序的控制权转交回客户端，由客户端决定接下来向用户展现什么内容。