本文旨在闡明 OAuth2.0 體系中第三方軟體和受保護資源服務的職責。
1 建構第三方軟體應用
若基于公衆号開放平台建構一個xx文章排版軟體的輕應用，需要先到公衆号開放平台申請注冊成為開發者，再建立個應用就可以開始開發了。
1.1 開發過程的關鍵節點
1.1.1 注冊資訊
xx軟體必須先有身份，才能參與 OAuth 2.0 流程。即xx需要擁有
app_id
和
app_serect
、自己的回調位址
redirect_uri
、申請權限等資訊。
這稱為靜态注冊，即xx開發人員提前登入到公衆号開放平台手動注冊，以便後續使用這些注冊的相關資訊來請求通路令牌。
1.1.2 引導授權
當使用者要使用三方軟體操作在受保護資源上的資料，就需要三方軟體引導
授權。
大家也很熟悉，我要使用xx來對我公衆号裡的文章排版時，我首先通路的
一定是xx軟體，而不是授權服務&受保護資源服務。
但xx需要我的授權，隻有授權服務才能允許我的操作。是以xx需要将我引導至授權服務
String oauthUrl = "http://localhost:8081/Oauth?reqType=oauth"; response.sendRedirect(toOauthUrl); 讓使用者為三方軟體授權，得到授權後，三方軟體才可以代表使用者去通路資料。即xx獲得授權後，就能代表我去排版文章。
1.1.3 使用通路令牌
第三方軟體的最終目的：拿到令牌後去使用令牌。目前OAuth 2.0 令牌隻支bearer 類型的令牌，即任意字元串格式的令牌。
官方規範給出的使用通路令牌請求的方式，有三種
Form-Encoded Body Parameter（表單參數）
URI Query Parameter（URI 查詢參數）
Authorization Request Header Field（授權請求頭部字段）
如何選型？
- OAuth 2.0 官方建議，系統在接入 OAuth 2.0 前資訊傳遞的請求載體是 JSON，若繼續采用表單參數送出，令牌就無法加入。
- 若采用參數傳遞，URI 會被整體複制，安全性最差。
- 請求頭部字段無上述顧慮，是以被官方推薦。
但小小推薦采用表單送出 POST 方式送出令牌，類似如下代碼所示。畢竟官方建議指的是在接入 OAuth 2.0 前，若你已采用 JSON 請求體條件下，才不建議使用表單送出。倘若一開始三方軟體和平台都一緻采用表單送出，就沒問題了。因為表單送出在保證安全傳輸同時，無需處理 Authorization 頭部資訊。
String protectedURl="http://localhost:8081/ProtectedServlet";
Map<String, String> paramsMap = new HashMap<String, String();
paramsMap.put("app_id","APPID_XX);
paramsMap.put("app_secret","APPSECRET_XX");
paramsMap.put("token",accessToken);
String result = HttpURLClient.doPost(protectedURl,HttpURLClient.mapToStr(paramsMap)); 1.1.4 使用重新整理令牌
解決痛點
若通路令牌過期了，xx總不能立馬提示讓我這客戶重新授權吧！
就需要重新整理令牌。重新整理令牌需注意何時決定使用重新整理令牌。
在xx排版軟體收到通路令牌同時，也會收到通路令牌的過期時間 expires_in。優秀的三方軟體應将 expires_in 值儲存并定時檢測；若發現 expires_in 即将過期，則需要利用 refresh_token 重新請求授權服務，擷取新的有效通路令牌。
除定時檢測可提前發現通路令牌是否快過期，還有“現場”發現。即比如xx通路我的公衆号文章時，突然收到一個通路令牌失效的響應，此時xx立即使用 refresh_token 請求一個通路令牌，以便繼續代表我使用我的這些文章資料。
可得：
- 定時檢測方案需開發定時任務
- “現場”發現，就沒這額外工作咯
還是推薦定時檢測，因可以帶來“提前量”，以便讓更好掌握主動權。
重新整理令牌是一次性的，使用後就失效，但它的有效期會比通路令牌長。
若重新整理令牌也過期呢？
需将重新整理令牌和通路令牌都放棄，幾乎回到系統初始狀态，隻能讓使用者重授權。