[筆記] 認識 OAuth 2.0：一次了解各角色、各類型流程的差異

OAuth 有分 1.0 及 2.0 版本，本篇內容皆是以 OAuth 2.0 為出發點做介紹。另外，本篇提及數個平台作為範例來說明綜觀的 OAuth 2.0 概念，實際的畫面與機制可能與該平台有所差異，若要獲得各平台最新與最詳細的設計，可以參考其官方文件。

OAuth 2.0 介紹

講到開發應用程式，身份驗證功能通常少不了，實作上有非常簡易的方法，也有利用更多技術，讓驗證流程更完善和安全。

陽春版驗證功能

最簡易的驗證機制（如下圖），是使用者在客戶端透過基本的帳號與密碼向後端伺服器驗證身份。伺服器會經過一連串的驗證流程，驗證成功後透過如 Session / Cookie 機制，在客戶端保存用戶登入的狀態資訊。

缺點：安全性與維護

陽春版的劣勢，是我們必須自己維護驗證的機制與穩定性，也必須隨時檢視使用的驗證和保存機制，是否符合當前普遍認為的安全性等。例如將密碼進行雜湊後再儲存與比對即是一個普遍的做法。

OAuth2.0 解決方案

我們在許多拜訪的網站想要登入時，時常能看到像下圖 Medium 登入跳窗，提供多種登入的方式。在不經意的點擊下，我們其實已經使用到 OAuth 的流程。

OAuth 是一個開發標準（Open Standard）用來處理有關「授權」（Authorization）相關的行為。

這個使用 OAuth 的流程白話來說：「我們允許並授權當前的應用程式（在這是指 Medium）有限度的取得我們在 Facebook、Google 或其他平台的相關資訊」——使用者身份驗證的工作基本上是委由選擇的平台完成，當驗證成功，且用戶同意，應用程式才得以前往取得所需要的資源。

Source: Medium Sign in Popup