OAuth 2.0 三部曲(1) - Open Authorization

前言

OAuth 2 適用於第三方開放授權的協議，這個協議規範了使用者如果通過第三方授權來讓應用程式可以取得使用者的資訊或是代表使用者採取某些行動。

為甚麼會想要寫這個研究主題? 主要是因為這一年來的專案都要用到第三方登入，第三方登入應該是 OAuth2 最常使用到的場合了呢~ 既然這麼常用也就順便看一下它的規範以及為甚麼會有這樣的演化吧!


圖 1. 2023文博會登入頁面

遠古時代 - 在 OAuth 協議之前

在最遠古的時候，使用者需要先向應用程式出示帳號以及密碼，應用程式接著再拿著這組帳號密碼代表使用者採取行動。

各位有想到那些問題呢? 可以先用筆寫下來再越過防雷線來看~

我是防雷線

下面是筆者給出的答案:

應用程式必須明碼儲存使用者的帳密
應用程式有使用者的帳密可以代表使用者做任何事
一旦其中一個應用程式被破解會導致使用該帳號密碼的資料都被破解

仔細思考可以發現問題在於應用程式一但拿到使用者的帳密根本就等於是使用者本人了，如果是這樣的話也就是說不能直接把帳密交給應用程式，那該怎麼解呢?


圖 2. 在 OAuth 之前的第三方授權流程

OAuth2: 來個授權伺服器吧!

聰明的人們決定引入一個中間層，這個中間層可以接收使用者的帳密，也可以讓應用程式在上面註冊並明訂要以使用者的名義做的事情以及範圍。

如此一來，應用程式不僅不用直接拿使用者的帳密，而且也可以定義清楚應用程式想要存取的權限範圍。

下面我們來看看在 OAuth2 協議裡面的各個行動者吧!

Resource User: 使用者(擁有帳密的人)
Client: 應用程式
User Agent: 使用者代理人(通常指瀏覽器)
AccessToken: 身分令牌，可以拿來存取使用者的資源
RefreshToken: 更新令牌，生存時間比身分令牌長，當身分令牌過期時可以拿更新令牌換取新的身分令牌
Authorization Server: 授權伺服器，負責核發存取令牌和更新授權令牌，同時也讓應用程式在其上註冊並開通存取權限的範圍
Resource Server: 資源伺服器，存放使用者的資源

其實最重要的就是 Authorization Server 了，他是應用程式還有使用者的裁判(?，由它來統一進行驗證/發放授權。

下友會介紹四個 OAuth2 的認證模式，但不管是哪個模式，都有 Authorization Server 的存在~

AuthorizationCode Grant Flow (授權碼模式)

這是一種最安全的方式。應用程式不直接向使用者要求許可，而是透過授權伺服器轉址的方式在轉回應用程式時夾帶授權碼給應用程式，應用程式再使用授權碼取得存取令牌，用授權令牌可以獲取受保護的資料。

這個流程讀者們可能會覺得拿 AuthorizationCode 換 AccessToken 怎麼這麼雞肋，為甚麼不直接給 AccessToken 就好，不過再仔細看看流程就會知道 AuthorizationCode 是在重新導向的時候夾帶的，如果是 AccessToken 被截獲就一切都拜拜了。

再注意到最後一個流程，Client 最後將 AuthrizationCode 還要再加上 secret 證明自己才可以拿到 AccessToken，這一步驟通常是在後端進行，所以不僅 AccessToken 不會外流而且 secret 也只要一直儲存在後端即可。

第二種認證流程就差在這裡，差別在於要不要拿 AuthorizationCode 換 AccessToken。

Implicit Grant Flow (隱含授權模式)

承上面所說的，隱含授權模式就差在要不要走 AuthorizationCode 這一步，如果不走的話就是直接在重新導向的時候把 AccessToken 帶回來囉!? 這樣好像就沒後端甚麼事了耶!

那通常是甚麼場景會用到這種模式呢?

隱含授權模式適用於前端 Web 應用程式，也就是在瀏覽器內執行 JavaScript 的應用程式。這類應用程式會使用 JavaScript 存取伺服器資源(通常是 WebAPI)，再更新頁面上的資訊。例如 :
Gmail 會依據使用者點選的收件匣的訊息，更新頁面上顯示的資訊，而不需要整頁重新導向(如果想要在瀏覽器直接拿到 AccessToken 的話)。

可是因為這個流程 AccessToken 存在瀏覽器，外露的風險大，所以在隱含授權模式裡面就不可以拿 RefreshToken 去更新 AccessToken。