OAuth原理與Laravel Passport實作(1)
本篇為學習OAuth 2.0實作而撰寫的簡易筆記，主要是講解實作並對應到原理，初淺的介紹OAuth 2.0在利用Laravel Passport實作OAuth 2.0，有些規範可能會漏說明或是不清楚還請多包涵，想知道OAuth 2.0 Spec可以參考RFC 6749或Markdown版，如筆記內容有誤歡迎留言告知
OAuth 概念
假設今天要使用某網站的服務，該服務需要存取某個第三方應用程式(Google、FB、Gmail)為了要讓A網站存取得第三方應用程式資源，所以使用者要授權A網站可以對第三方應用程式做存取，所以會在客戶端與服務端中引入一個認證層 (authorization layer)，客戶想要存取服務端的資源要先透過認證層拿到存取權限(令牌)，在透過此權限來訪問服務端做存取資源的動作
PS: OAuth 2.0是建立在HTTPS傳遞下，所以傳遞資料的過程需走HTTPS，因為資料有洩漏的疑慮(參考 Spec 的 1.6. TLS Version)
OAuth 角色互動關係
在OAuth 2.0 中主要有四個角色
- Resource Owner : 使用者(網站用戶)
- Resource Server : 資源(Google雲端)
- Client : 想要存取Resource Server(雲端資料)的網站
- Authorization Server : 發放Client可以存取Resource Server的授權
Authorization Server 與Resource Server 兩者可以同一台也可以分開
這四個角色互動關係傳遞的資料會因Grant Flows(OAuth內建授權流程)而不同，主要是看業務邏輯來決定使用哪一種Grant Flows，後續會提到
參考 Spec 的 1.1. Roles
假設角色：
- 小明（Resource Owner）
- 圖片編輯網(Client)
- Google雲端（Resource Server）
- Google OAuth（Authorization Server）
資料定義：
- Authorization Request是一種用來請求授權認證碼許可或是Access Token
- Authorization Grant是一個授權許可，用來取得Access Token
- Access Token是一種認證碼，用於跟Resource Server存取資料
- Protected Resource是Resource Server上的資料
Authorization Request取得的內容跟Grant Flows流程有關，後續會提到
步驟：
- (A)小明想要登入圖片編輯網使用圖片功能，於是圖片編輯網就發出一個Authorization Request請求跟Google OAuth說有一位使用者想要請你授權Google雲端存取的權限給圖片編輯網
- (B)小明看到透過Authorization Request請求後所產生的授權網頁後，可以選擇是否授權與權限範圍給圖片編輯網來存取小明在Google雲端上的圖片，小明說好，我授權給圖片編輯網，Google OAuth就發送一個Authorization Grant給圖片編輯網
- (C)圖片編輯網拿到Authorization Grant再發送這個Authorization Grant給Google OAuth經過認證確認是Google OAuth發行給圖片編輯網的許可
- (D)Google OAuth就回傳一個Access Token給圖片編輯網，這個Access Token就是小明授權給圖片編輯網來存取Google雲端的一種鑰匙
- (E)圖片編輯網拿到小明授權的Access Token後就發給Google雲端說我是小明的代理人我來幫他存取Google雲端的圖片
- (F)Google雲端認證Access Token確實是Google OAuth發行，內容也都合法就回傳圖片給圖片編輯網
Authorization Request(授權請求)
假設來到某個網站選擇用第三方登入(OAuth)此時該網站就會跳到第三方登入介面，這個介面就是Client請求Resource Owner授權權限的介面，權限項目就如個人檔案、電子郵件，右邊可以勾選權限(如下為FB OAuth登入示意圖)，當Resource Owner授權後就會發出請求去拿Authorization Grant，這個請求就是Authorization Request
Authorization Grant(授權許可)
在取得Access Token前一步的授權，這部分屬於OAuth內建四種授權認證流程(Grant Flows)中的Authorization Code才會有這個流程，如Implicit Grant就不會有Authorization Grant而是當Authorization Request完成後直接回傳Access Token，後續會討論到Grant Flows，這邊先知道Authorization Grant是在取得Access Token前先取得許可再透過這個許可去取Access Token
Access Token(訪問令牌)
Access Token是用來訪問Resource Server的一種字串，Access Token內可以有時效(expires)、範圍(scope)，具題的內容由Resource Owner授權，而這些授權的內容規範則由Authorization Server與Resource Server定義，比如Authorization Server可以定義某些Access Token的expires為幾天等，Resource Server可以定義一個scope可以存取某個資料，然後由Authorization Server綁定在Access Token上
Access Token也可以做加密的數位簽章以防止傳輸過程中有人串改Access Token，如將Token做成jwt
以下為常見的Access Token用法，當接收到Access Token如果必須包含token_type且使用Access Token時需要帶此type
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
Authorization的Value格式為 Bearer [Token]，Bearer與Token之間要有一個space在Spec中Access Token並未交代如何做與使用，這些則定義在RFC 6750(Bearer Token Usage)
Refresh Token(刷新令牌)
Client接收到Authorization Server給的Access Token後也拿到Refresh Token並保存起來，等待Access Token快要過期時向Authorization Server發送Refresh Token取得一組新的Access Token，這樣的好處在於不需要再一次透過Resource Owner拿Authorization Grant再向Authorization Server拿Access Token，減少對Resource Owner的請求
Refresh Token並不是每一種Grant Flows都會使用到，當Authorization Server給的Access Token具有expires哪麼回傳Access Token時也要一併回傳Refresh Token
假設角色：
- 延續OAuth 角色互動關係的定義
資料定義：
- 延續OAuth 角色互動關係的定義
步驟：
- (A)圖片編輯網出拿出經由小明授權的Authorization Grant給Google OAuth
- (B)Google OAuth經認證沒問題確實合法，回傳一個帶有expires(時效)的Access Token與負責刷新Access Token的Refresh Token
- (C)圖片編輯網向Google雲端出示Access Token
- (D)經過Google雲端認證此Access Token合法後就回傳圖片
- (E)圖片編輯網再次向Google雲端出示Access Token
- (F)由於該Access Token具有expires且期限已到，Google雲端回傳Invalid Token Error，告知圖片編輯網，這個Access Token已經不可以用了
- (G)圖片編輯網得知Access Token不可用後，向Google OAuth出示Refresh Token說我要刷新Access Token
- (H)Google OAuth驗證Refresh Token的合法性後再次回傳Access Token，而Refresh Token是否在再核發端看各業務邏輯，
(E)到(H)就是執行Refresh Token的流程
Access Token如何檢查過期與權限是否足夠，就看各位業務邏輯與實作