Oauth2.0（二）：开放平台

在上一篇文章《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，并且鉴权服务器的受权动做已经完成，恰好能够把程序的控制权转交回应用方，由应用方决定接下来向用户展现什么内容。

更多技术文章，请关注我的号：