近來工作上遇到要做 SSO 網站，大致理解這個技術是透過單一入口，減輕使用不同服務時重複登入的負擔。
但除此以外……就沒有更深入的理解了 🥲，雖然可以製作出介面與流程，卻無法明白這些流程為什麼這樣走，系統架構為什麼這樣設計。常抱著畫面請工程師說明，但每次詢問的內容無法在腦中拼湊成完整的概念，因此很難記住。
也嘗試自己搜尋網路資料，卻遇到一樣的問題，看過就會忘記 XD。沒辦法真的變成自己的 know-how。據說最有效的學習是自己消化過然後輸出，於是就有了這篇學習筆記的誕生！讓我們開始吧 😆。
SSO 簡介
SSO （Single Sign-On 單點登入），描述的是一種概念，可以藉由單一入口，使用多個服務。而這些服務會向一個管理中心認證使用者的會員身份。
舉例來說就像 X 港音樂祭、大 X 音樂祭，販售的是實名制的門票。參加者需要先到手環兌換處，查看證件完確認是本人了之後，會發一條手環。接著，就可以靠這條手環進出各個表演場地，不用每次都拿出證件來驗票。
p.s. 實際上發給每個使用者的 token （音樂祭手環）並不是同質的，但希望夠過這個舉例，讓人感受到 SSO 的方便之處。
SSO 這個概念其實由來已久，最早可以追溯到 1980 年代。當時主要的應用情境是企業內部的服務，使用者可以用單一組身份登入多個服務，這些資訊是在一個區域網路內進行交換，因此實作方式和現在也不太相同。
1990 年代，SSO 開始在網際網路上流行。隨著網際網路的普及，越來越多的公司提供網站和應用程式，使用者需要在不同網站各自設定帳號密碼，使用者有能力管理並記憶這些密碼嗎？有調查指出，接近八成的人，在過去三個月間曾經使用過重設密碼的功能，顯見密碼被遺忘或記錯是經常發生的事 😌。
2010 年之後，逐漸出現第三方登入（TPL, Third-party login）的登入模式。也被稱為 Social login，是 SSO 的一種類型。使用者可以使用既有的社群帳號來登入其他服務。
2015 年 Facebook 開始提供 Facebook Login 的服務，Google 則在 2016 年相繼推出類似服務。對串接 TPL 的應用程式來說，省去了驗證使用者身份的作業。而對於使用者來說，能夠使用自己既有社群帳號登入應用程式，不需要再創建一組帳號密碼，也減少了進入應用程式的摩擦。
使用 SSO 的優點 （引用自這裡）
- 不用重新建立使用者帳號
- 減少記憶密碼，降低使用者排斥新系統
- 安全性提升
- 可以有多種認證方式
其中第三點與第四點其實是基於身份驗證交由單一組織管理，從而有更多資源維護身份驗證實作上的資訊安全。畢竟身份驗證與管理的維護成本也是挺高的。
實例
現在 SSO 已經是許多大型軟體服務採用的身份管理模式。可以透過觀察網域來看出服務的分界線。
以使用 Google Meet 為例，首頁的網域在 apps.google.com。
點擊發起會議後，會導向至登入頁面，此時已經重新導向網域 accounts.google.com。
再試試另一個應用程式 — — Google Calendar ，應用程式本身位於 workspace.google.com。
點擊登入，會導向 accounts 這個網域。
Google 的眾多服務共用同一組身份認證機制，在需要登入時，將使用者導向 accounts 網域進行登入，完成後再導回應用程式繼續使用。
運作流程
這裡舉例比較常見、基於網頁的運作方式，SSO 也有其他的實現方式和應用情景。以下是 WSO2 提供的流程圖。
註：WSO2 IS 是一個 CIAM 平台，可幫助組織安全高效地管理客戶身份和訪問權限。簡單來說，它提供了架設 SSO 的工具以及伺服器。
試著翻譯並以 Google 第三方登入為例。整張圖可分為上下兩部分。上半部描述了進入網站、選擇 Google 第三方登入並且重新定向至 Google 進行登入的過程。
是不是在中間看到了很多 cookie 呢？SSO 的主流實作方式，很大程度仰賴 cookie 來提升使用體驗。cookie 是瀏覽器儲存在本機端的一小片資訊，在傳送網站訪問請求時會一併送出。證明登入狀態的 token 也可以放在 cookie 中保存。實際上達成的效果就是，使用者只要登入一次，這個登入狀態就可以保持一段時間 ✨。
在圖的下半部，使用者進到 App2 ，也選擇 Google 第三方登入時，由於 cookie 已經存在著登入狀態，就不需要再次輸入帳號密碼進行登入了。
SSO 的使用過程中會一直在網站間切換，其中一個原因是 cookie 通常不能跨網域使用。當使用者訪問 App1 的時候，是無法取得 Google 的登入狀態的。
即使 Google 一直保持登入狀態，也必須要重定向到 Google 的網站才有辦法取得 Google 網域下的 cookie （步驟 9 & 10），從而驗證你的登入狀態。
以上就是 SSO 的簡易說明，想更了解運作原理的人可以看這一篇。
設計要點
由於登入流程會跨越不同網站，頁面重新載入是不可避免的。且頁面風格也可能不一致，更需要謹慎處理，避免讓使用者感到困惑或不信任。
無論設計師身處的團隊是用怎樣的方式使用 SSO，也許是串接第三方登入、使用母公司的 SSO 服務，甚至是自己建立 SSO 服務。以下幾個要點，也許能幫助你檢視設計內容是否適當。
- 全盤性的檢視流程
將使用的歷程攤開檢視，自有產品與外部服務也許會穿插出現。在這個階段，盡量擷取畫面、將流程做視覺化存檔，有助於團隊討論和流程設計。
2. 清楚的呈現服務間的關係 & 行為後果
情況也許是這樣：產品 A 和產品 B 都使用了 C 公司的 SSO 服務。ABC 之間是否有從屬關係？這些服務是由誰提供的？使用者對這些名稱可能並不熟悉，需要適時的加上相關說明。以下舉例為使用 Confluence 時的登入畫面，頁面下方有一段文字說明了用以登入的 Atlassian 帳號與其他服務間的關係。
3. 隱私與授權
使用 SSO 可能會向第三方程式揭露個人資訊，有時有授權範圍的變更。確保介面能夠清晰的傳達這些資訊，以幫助使用者掌握情況。
以上就是 SSO 的相關說明，希望看完之後能帶給你們一點收穫。如果有解釋不清或錯誤的地方，歡迎留言，我會很感謝你的 🥺
參考資料
