WEB使用OAuth2协议实现开放接口的设计方案（待完善）
术语
developer：开发者，第三方应用的开发者。
openPlat：开放平台，发放App Key（相当于第三方应用的ID）、App Secret（私钥，验证ID是否唯一有效，需要妥善保管）。
Authorization Server：授权服务端，发放Code、Access Token，验证App Key、App Secret、Code的有效性。
Resource Server：资源服务器，验证Access Token，提供资源的访问接口。
Client：客户端（第三方应用），发送访问受保护资源的请求，获取Code、Access Token。
Resource Owner：资源拥有者，对保护资源有访问许可控制的实体（一般是指个人）。
Protected Resource：受保护的资源，能够通过OAuth2.0获取访问控制权的资源。
Authorization Code：授权码
Refresh Token：刷新令牌，Access Token失效后刷新Access Token的一个标识。
Access Token：访问令牌
API：资源封装为接口对外开放，得到访问授权的第三方应用可以调用API。
架构
开放平台
功能
发放App Key、App Secret
第三方应用在WEB提供的开放平台注册，提供回调地址；开放平台生成App Key、App Secret，并返回给第三方应用。授权服务器通过App Key、App Secret、回调地址验证第三方应用是否被授权了。
接口设计
获取App Key、App Secret的接口
传入的参数：
Client name：第三方应用的名称
Callback_url：回调地址
content：介绍内容
以及第三方应用的其他属性。
传出的参数：
App key：第三方应用的ID
App Secret：密钥
页面设计
申请获取App Key、App Secret页面
收集以下参数：
Client name：第三方应用的名称
Callback_url：回调地址
content：介绍内容
以及第三方应用的其他属性。
返回App Key、App Secret页面
呈现第三方应用的App Key、App Secret给开发者。
授权服务端
功能
发放Code
授权服务器验证用户的凭证（一般是用户名、密码，授权服务器存储了大量的用户信息，每个用户都有自己的受保护的资源）有效，则给发放Code，并将Code返回给第三方应用。Code是明文传输。
发放Access Token
第三方应用使用Code去换取Access Token。此时验证第三方的ID（App Key、App Secret）、Code的有效性。
验证App Key、App Secret
授权服务器保存已经注册的第三方应用的App Key、App Public Secret（公钥），通过私钥验证第三方应用是否已经注册。
验证Code
验证Authorization Code是否有效。
接口设计
设计两个接口：a、获取Code的接口；b、获取Access Token的接口。
获取Authorization Code的接口
客户端向资源拥有者请求授权，资源请求直接发给资源拥有者，若资源拥有者同意该客户端授权，则给客户端返回一个访问许可。
传入的参数：
App Key
App Secret
Callback_url
返回的信息：
未登陆、微授权：跳转到登陆页面；
已经登陆、未授权：跳转到授权页面；
已经登陆、已经授权：跳转到传入的callback_url页面，并返回一个访问许可。
获取Access Token的接口
客户端向用户出示自己的私有证书和Authorization Code请求访问令牌；授权服务器验证客户端的私有证书和访问许可的有效性，验证有效则向客户端发送一个访问令牌，令牌包括了作用域、有效时间以及其他属性。
传入参数：
App Key：应用的ID
App Secret：第三方应用的私钥。
Callback_url：回调url
传出的参数：
Access Token：Access Token中包含了AppId和用户信息UserIdd等。
获取到Access Token
之后，就可以向资源服务器出示Access Token，访问受保护资源。
页面设计
设计两个页面：a、登陆页面；b、授权页面
登陆页面
展示给资源拥有者，输入用户名的、密码。登录成功后，如果未授权，则跳转到授权页面；如果已经授权，直接跳转到callback_url页面，并返回一个访问许可。
授权页面
展示给资源拥有者，如果用户已经授权，则直接跳转到callback_url页面，并返回一个访问许可；如果未授权，则出现授权页面，授权成功后，跳转到callback_url，并返回一个访问许可。
第三方应用接入WEB