[筆記] 認識 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 或其他平台的相關資訊」——使用者身份驗證的工作基本上是委由選擇的平台完成,當驗證成功,且用戶同意,應用程式才得以前往取得所需要的資源。