Social Login和Single Sign On簡介

雜談

Hi，這裡是PK還在廢，一個坑還沒填完就開始挖新坑了，學習的道路上滿路瘡痍XD。這次也是因為工作所接觸到的，User希望可以在進入網站前進行認證，並且記錄相關認證資訊，避免重複登入導致的時間浪費。在這之前沒有特別處理過身分認證的問題，因為以前的專案都是本地端隨便跑( 被揍。難得有這個機會決定來找找相關解決方案，並記錄下來和大家分享d(`･∀･)b。

傳統網頁驗證架構

以上是傳統的網頁驗證架構，一般會於後端架設自己的Authentication Server。當User登入後會傳遞登入請求到Frontend Server， Frontend Server再將User輸入的資料加密傳遞到Authentication Server進行認證。如果認證成功會傳遞相關用戶資料或Access Key之類的資訊給Frontend Server使用，反之如果失敗會顯示error message，提示用戶哪邊錯誤。

這個架構的好處是很簡單易懂，前期架設其實很簡單，但缺點是需要花費額外的心力去維護Authentication Server。服務商需要具備相關資安技術，並且要自行處理資料加密與安全性升級。此外，對於User來說我每個網站都需要創一個帳號，管理起來會超級麻煩。想必大家都有久久想登入卻想不起密碼的情境吧，當下應該氣到快翻桌了(／‵Д′)／~ ╧╧。

這邊簡單整理一下傳統網頁驗證架構的優劣 :

優點
1. 容易理解和架設
缺點
1. 服務供應商需要自行維護一套Authentication Server，需要具備相關資安技術
2. 對User來說，額外創立帳號很難管理且容易忘記
3. 每次都需要花費時間重新登入

那要如何改善這些缺點呢? 其實大家平常已經很常接觸到了，就是透過綁定大型的社交帳號來創建服務的新帳號，這種機制叫做 Social Login，常見的就是Google Account, Apple Account, Microsoft Account等等。你只要有一組帳號就可以在各網站或服務註冊帳號，並且登入對應帳號就可使用。

Social Login都會遵循OAuth這個開源的無密碼登入(Passwordless Login)標準，OAuth允許使用者讓第三方應用(Frontend Server)訪問特定網站(OAuth Provider)的用戶授權與資訊，並且不會將密碼資訊傳遞給Frontend Server。有點文言對吧，簡單來說特定網站(Google, Apple, etc.)是擔保人或信託機構，具備公信力與相關用戶資訊。User授權Frontend Server去跟這些OAuth Provider要User的相關資料，以下是簡化的流程圖 :

💡 OAuth後續還有提出OAuth 2.0，以及新版本基於OAuth 2.0擴展的Open ID Connect (OIDC)，如果未來有空會簡單介紹，這裡挺複雜的( ˘•ω•˘ )。

User會選擇對應的OAuth Provider， Browser會依據選擇導向到對應的OAuth Provider，並且獲取授權碼(Public key, Token, etc.)，這串授權碼會加密。有些系統會讓授權碼保留在Browser的Cookie，方便每次登入確認是否過期?是否需要重新登入?

授權碼雖然也會過期，不過一般時間會比較長，而時間較短的是Access Token，這個Token具備於OAuth Provider獲取使用者資訊的權限，會被傳送至Frontend Server進行相關邏輯判斷或資料獲取。完成資料獲取或操作後，系統會將結果傳遞回Browser讓網頁重新導向或刷新頁面。