伺服器端的資料儲存方案

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，訪問受保護資源。