上一节说到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，而且鉴权服务器的授权动作已经完成，刚好可以把程序的控制权转交回客户端，由客户端决定接下来向用户展示什么内容。