OAuth2.0 机制的核心工作流程，大部分信息，如APP 信息、用户和APP 之间的授权关系、Access Token等，需要永久性存储，存储在数据库中。一些不需要永久存储的信息，如临时授权码，只使用一次，而且，在很短的时间内就要使其失效，就没有必要存储在数据库之中，可存储在譬如memcached 等缓存系统中，即提高了系统的处理速度，又减少数据库压力。数据库表结构设计：客户端要先注册一个应用，获取该应用的APPID和APPSECRET，应用的详细信息存储在数据表中，如下所示：
表1 appinfo APP 信息存储表
字段 备注
appid client_id
appsecret client_secret
appname 应用名称
appowner 应用的所有者
owneremail 应用拥有者的email
appdescribe 应用描述
status 应用是否通过审核
callbackurl 跳回的url
addtime 添加时间
表2 authorize 授权关系存储表
客户端与资源拥有者是“多对多”的关系，如下表
字段 备注
appid 应用ID
userid 用户ID
addtime 添加时间
表3 access_token 访问令牌存储表
字段 备注
access_token 访问令牌
addtime 添加时间
服务器端需要提供的接口和页面
服务器端需要提供两个接口和两个页面：两个接
口，一个是用来获取访问许可的接口，一个是用来获
取Access Token 的接口；然后再提供一个登录页面和
一个授权页面。
获取访问许可（Authorization Code）接口
客户端从资源拥有者（最终用户）那里请求授权。授权请求直接发送给资源拥有者，如果资源拥有者为该客户端授权， 则给客户端发送一个访问许可(Authorization Code)：
传入参数：
appid 应用ID
callback_url 回调URL
返回信息：
未登录、未授权：跳转到登录页面；
已经登录、未授权：跳转到授权页面；
已经登录、已经授权：跳转到传入的callback_url页面，并返回一个访问许可。
登录页面
这个页面展示给资源拥有者，输入用户名、密码，登录成功之后，如果未授权，则跳转到授权页面；如果已经授权，直接跳转到callback_url 页面，并返回一个访问许可。
授权页面
这个页面也是展示给资源拥有者，如果用户已经授权：则直接跳转到callback_url 页面，并返回一个访问许可；如果用户未授权：出现授权页面，授权成功之后，跳到callback_url 页面，并返回一个访问许可。
获取Access Token 接口
客户端向授权服务器出示自己的私有证书和上一步拿到的访问许可，来请求一个访问令牌（AccessToken）；授权服务器验证客户端的私有证书和访问许可的有效性，如果验证有效，则向客户端发送一个访问令牌，访问令牌包括许可的作用域、有效时间和一些其他属性信息：
传入参数：
Appid 应用ID，client_id
Appsecret client_secret
callback_url 回调URL
authorization_code 访问许可
返回信息：
Access Token，Access Token 中包含APPID 和用户信息userID 等。获得Access Token 之后，就可以向资源服务器出示Access Token，访问受保护资源。
联系客服
