接下來幾天，想完成第三方登入的功能。
因此今天會先梳理第三方登入原理，預計明天才開始實作。

什麼是第三方登入？

第三方登入是一種身份驗證機制，讓使用者不需要在許多網站註冊帳號，取而代之以透過登入其他已註冊的平台(如 Line, Google) 等來驗證自己的身分。
這麼做對使用者來說除了方便（省去註冊流程、減少管理多組帳號密碼的負擔），也比較安全（避免某些網站未安全管理資訊，造成帳號密碼洩漏）。
對應用程式來說，提供第三方登入的功能也會大幅提升使用者體驗，因此第三方登入功能在現代網站也蔚為流行。

什麼是 OAuth2.0 ？

OAuth2.0 是一個開放標準的授權協議，它允許應用程式(例如我們的網站)代表資源擁有者(例如網站的使用者)，在不洩露使用者密碼的情況下，訪問資源擁有者在第三方服務(例如Google)的資源(使用者存放在第三方的資源，例如提供給Google的個人資訊、email、大頭貼)。

此外，OAuth2.0 主要關注的是如何取得使用者授權，會定義授權有哪些流程、參與的角色這些大概念，實作細節則不在其規定範圍內。

因為 OAuth2.0 就是實現第三方登入功能背後的授權核心框架，接下來我們會介紹 OAuth2.0 定義的角色與最常見的流程：

OAuth2.0 中的角色

• 資源擁有者 (Resource Owner):通常是指使用者，擁有資料的存取權限。
• 用戶端 (Client):想要存取使用者資源的應用程式。
• 資源伺服器 (Resource Server):存放使用者資源的伺服器。
• 授權伺服器 (Authorization Server):負責驗證使用者身分並發放授權給用戶端。

OAuth2.0 的授權流程 (grant type)

OAuth2.0 定義了多種授權流程，以下僅詳細介紹最常見的流程。

• 授權碼流程 (Authorization Code Flow)
  比起其他流程，授權碼目前被認為是最安全的流程，其適用於伺服器端應用程式，流程大致如下：

  1. 用戶端將使用者導向授權伺服器，請求授權。
  2. 授權伺服器驗證使用者身份並取得使用者授權同意。
  3. 授權伺服器將使用者導回用戶端，並附上一個授權碼 (Authorization Code)。
  4. 用戶端使用授權碼向授權伺服器交換存取權杖 (Access Token)。
  5. 用戶端使用存取權杖向資源伺服器請求存取使用者資源。

  

  圖片來源：OAuth 2.0 授權流程

  以上授權碼流程有兩個重點：

  • 為什麼要多一個透過驗證碼取得 Access Token 的過程？

    主要是因為驗證碼會附加在 Redirect URI 的 Query String 中，任何人都看的到這個 String。因此在前後端分離的架構下，通常會由前端向後端傳送這個授權碼，再由後端以此授權碼去向授權伺服器換取 Access Token。

  • 使用者授權作業都是與授權伺服器溝通。

    用戶端不會介入使用者授權的流程，增加了避免被惡意網站自行操作授權的安全性。

除了授權碼流程，OAuth2.0 還定義了以下流程：

• 隱式流程 (Implicit Flow)：整體流程類似授權碼流程，但省略了授權碼的部分，直接在前端傳遞 Access Token，安全性較低，在過去常用於純前端的單頁應用程式 (SPA)。不過，此流程目前已被 OAuth 2.1 規範棄用，並由安全性更高的「授權碼流程 + PKCE」所取代。
• 設備碼流程 (Device Flow)：用於無法直接輸入文字的設備，例如智慧電視或物聯網設備。
• Resource Owner Password Credentials：由使用者提供帳號與密碼等資訊給應用程式，由應用程式直接向 Authorization Server 交換 Access Token。適用於公司內部的系統

應用程式應該根據需求選擇適用的流程。

什麼是OIDC？

理解了 OAuth2.0 後，最適合緊接著介紹OIDC。

因為 OAuth2.0 主要講的是授權，也就是使用者授權應用程式取得自身存於第三方的資源。雖然流程上應用程式拿到 Access Token 後，會去第三方資源伺服器取得使用者資訊，但此時我們是比較像間接得知使用者資訊，而非直接驗證使用者身分，因此後續才衍生出了 OIDC 的概念。

OIDC 全稱為 OpenID Connect，是基於 OAuth 2.0 的機制上增加身分驗證層 (Identity Layer)，讓應用程式可以確保使用者身分，以下說明 OIDC 比起 OAuth 2.0 具體上有那些差異：

OIDC中的角色

OIDC 與 OAuth2.0 中的角色用詞與概念上有些差異，但相去不遠，整理如下：

OIDC 在 OAuth2.0 的流程差異

流程上基本上無異，主要是流程間傳遞的資訊多了 ID Token。

這個 ID Token 是以 JWT 的方式簽發， 由身份提供者（例如 Google）用私鑰簽章，應用程式可以用公鑰來驗證它的真偽。如同先前介紹 JWT 的概念，Token 裡面包含了標準化的使用者身份資訊，例如：

• iss：簽發者 (Issuer)
• sub：使用者唯一識別碼 (Subject)
• aud：接收者 (Audience)，也就是我們的應用程式
  等...。

實作時，OIDC 比起原本的 OAuth2.0 會有著以下的差異：

• 請求時，scope 新增 openid ：
  • 在將使用者導向 Google 時，除了請求 email、profile 等權限外，還必須加上 openid。告訴 OpenID Provider：「嘿！除了授權，我還想順便做身份驗證！」
• 交換 Token 時，多拿到 ID Token：
  • 當後端伺服器拿著授權碼去跟 Google 交換 Access Token 時，因為 scope 中包含 openid ，OpenID Provider 會在回傳 Access Token 的同時，多回傳一個 ID Token。
• 驗證 ID Token，完成身份認證：
  • 後端拿到 ID Token 後，用 OpenID Provider 提供的公鑰驗證其簽章。驗證通過後，我們就可以安全地從 Token 的 Payload 中解析出使用者資訊，完成登入或註冊。

參考了很多篇文章整理出今天的內容，應該足以作為我們後續實作的基礎。
礙於篇幅很多細節沒有在這篇深入說明，如果還想得知更多細節，網路上有許多大神的說明，例如今天流程圖的資料來源 Mike 大，跟這篇 在Medium上發表的文章，都介紹的非常詳盡！

如果內文有誤，一樣請各位請不吝提出:)！