台灣的Web工程師

前言

最近遇到公司裡好幾位年輕人在問OAuth的流程，所以寫在這裡分享給大家。

流程圖寫得很簡單，所以我們來一一說明一下每個Request 與 Response之間的關係；但在這之前，有幾點需要讀者提前先瞭解的，我們也在這說明一下。

前提知識

1.  Http Response 302，簡單來說，就是告知瀏灠器，你下一個要去的網址，而這個網址會放在Response的Header裡，一個Location的KEY裡面。
2. 處理302這件事是瀏灠器，並不會經過前端或後端的程式。

流程說明

下面我們開始來說明整個OAuth的流程，建議讀者一邊看圖，一邊看下方的說明文：

1. 使用者觸發Request　—　由使用者決定何時要進行登入，通常指的是使用者按第三方登入的按鍵的時候，例如要進行Google的登入時，使用者會按下Google圖示的按鈕。
2. AP Server 回應 302 — 由1帶進入的資訊決定使用者想進行的第三方登入是那一個，例如Google/Fackbook之類的，然後AP Server回應302將使用者帶到應對的第三方進行登入流程，這邊要注意的事情：
   • 網址需要OAuth端提供。
   • AP Server 要將特定的參數用Get的方式，帶到302的網址裡。
   • 特定的參數通常為clinet_id，redirect_uri，state，scope，其中client_id由OAuth端提供，redirect_uri由使用者在OAuth端設定，state裡AP Server決定要帶什麼參數，scope決定權限的部份。
   • state的參數部份，為了方便瞭解，我們假設state={"path": "project/list"}，這資料經過urlEncode後帶到302的網址裡，方便後續說明。
   • scope需要在OAuth端設定，用以決定最後使用者能取到的資料權限。
3. 瀏灠器收到302後，將使用者帶到OAuth的頁面進行登入，3.5即為使用者與OAuth端互動登入的部份，互動時，使用者可以透過scope的項目，大至瞭解會被AP Server取用什麼樣的資料。
4. 當OAuth端確認此人為OAuth的使用者後，一樣會帶302，讓瀏灠器將使用者導回我們AP Server，一樣，要注意的部份如下：
   • 導回的URL為步驟2的redirect_uri參數決定。
   • 參數一樣透過Get的方式帶到網址裡。
   • 參數會有二個，一個是code，一個是state；code是由OAuth確定使用者登入後產生的，state此時會回state={"path": "project/list"}的urlEncode編碼的結果。
   • 換句話說，state是由使用者來決定要寫什麼的，OAuth只是單純的幫你帶回來。
   • 若程式前後端分離的話，此時的redirect_uri要導回前端，由前端的程式來進行後續處理。
5. 瀏灠器收到302，幫導回AP Server，我們分前端程式與後端程式來說明：
   • 導回前端程式的話：拿到網址列的code及state，將相應的參數帶到後端，其中code一定要帶到後端，由後端進行下一步的處理。
   • 導回後端程式的話：根據參數拿到code及state，並進行下一步的處理。
6. 此時後端Server已拿到code的參數，需要client_id, client_secret, redirect_uri, code，這四項帶給OAuth Server，OAuth Server若判斷沒有問題，會回Token給後端的AP Server；這裡有幾點要注意的如下：
   • client_secret此時才會出現，這個參數從頭到尾都不會告訴前端，以防止使用者取得client_secret．
   • redirect_uri需與步驟2的redirect_uri一至，否則不會通過OAuth的驗證
   • code通常會一次性的東西，換完Token就失敗了，而Token時有時效性的東西，過期可以參考OAuth裡的Refreash Token說明文件。
7. 當OAuth確認步驟6的資料沒有問題的話，就會回Token給AP Server．
8. AP Server取得Token後，再發一次OAuth API去要使用者的資料。
9. OAuth 會根據Token的權限，給予AP Server資料。
10.  AP Server根據取得的OAuth資料，得到user資料並進行處理，此時已經可以判定使用者是誰了，所以AP Server可以給出自用的Token或Session給前端；注意一下：
    • 自用Token跟OAuth的Token是二件事，不要混用了。
    • 因為OAuth Token可以與OAuth溝通，所以通常OAuth的Token不會回給前端，以免使用者亂用。

結論

OAuth在現行系統上已可說是非常普遍地在使用中，不過其核心流程就如上方所描述的，所以讀者只要緊記這套流程，再根據你實際上遇到的案件去一步一步解決，基本上OAuth應該就不太會有什麼問題了。