Single Sign-On (SSO) 是什麼？
單一登入 (SSO) 是一種身份驗證解決方案，使用者只需要一組認證資訊，就可以訪問多個應用程式和網站。對使用者來說非常方便，不需要記住多個密碼，也不需要執行多次登入，有效提高使用者的方便性和安全性。
延伸閱讀 SSO 👉👉👉
當我們談到 SSO 登入機制時，可以分為兩種主要情況：
- 全新產品設計 SSO 機制
- 多個既有應用程式 (服務) 導入 SSO
一般來說，大型企業導入 SSO 的過程（例如：集團併購後整合多個服務），設計師往往難以參與，除了機會本來就少之外，工程師也扮演較為主導的角色。然而，在我接觸 SSO 專案後，發現不少設計可切入的方向，因此整理工作所學，分享一些觀點給大家。
本篇文章著重在既有服務導入 SSO 的差異、SSO 介面的必要條件，以及其他設計要點。（不會說明 SSO 基礎知識～🖐️）
一、多個既有服務導入 SSO
企業進行「既有服務導入 SSO」相對於「一開始就創立 SSO」，會面臨一些獨特的困難點和差異（開發人員不用考量現有服務或系統限制😹）。
1–1 現有帳號整併
將現有帳號整合到 SSO 系統中，以實現統一登入可能是複雜的，尤其是用戶在多個應用程式中擁有不同的帳號時。需要設計整併帳號的流程，包括用戶驗證和帳號關聯（詳情請看2–2）。以下是理想的做法：
- 未經用戶同意，系統不主動合併帳號
- 由用戶選擇一個現有帳戶作為主帳戶，尊重用戶的權益和喜好
舉例來說：
原先集團旗下服務（應用程式 A、B）會員池各自獨立，皆導入 SSO 後，可使用一個集團會員帳號登入所有服務。當會員擁有多組帳號（應用程式 A、B）時，系統將提示其進行集團整併帳號。
1–2 SSO 會員密碼
帳號整併的過程，用戶可能同時擁有多組帳號密碼，這就涉及到要以哪組密碼作為 SSO 密碼。原則是為用戶提供清晰的密碼整合流程，確保用戶理解密碼的處理方式，包括驗證現有密碼，以及在需要時重設密碼。
- 方法1：讓用戶選擇保留哪組帳號及密碼（如下圖）
- 方法2：讓用戶重設密碼以符合新的標準（1–3 整合密碼規則/方法1）
- 方法3：考量其他服務開發狀況，討論出 SSO 自定義規則，例如：用戶輸入哪組密碼登入，則以該組密碼作為 SSO 密碼。
1–3 整合密碼規則
在整合 SSO 時，不同應用程式和系統可能使用不同的密碼規則、Hash 解碼機制等，因此是否要統一密碼格式將影響用戶體驗流程。（本篇不會討論更複雜的密碼學）
- 方法1：調整滿足統一格式標準，在整併帳號的流程中，讓用戶重設密碼。
- 方法2：不整併密碼格式，各服務端及 SSO 需處理所有 Hash 加解密方法，整合上需花比較多時間。（前提條件：沒有其他難以整合的內容）
上述幾種方法，在使用上沒有絕對標準，仍須依照實際情境決定流程及細節，考量「既有服務的限制」仍然是整併 SSO 最麻煩也最複雜的部分。
二、SSO 介面的必要條件
除了上述要點外，不論是哪種情境，導入 SSO 都可能遇到：
2–1 重新簽署用戶協議和隱私權條款
根據「個人資料保護法」規定，企業在取得使用者同意之前，必須告知被搜集者個資法上所要求的告知事項，才能取得「有效同意」。導入 SSO 可能影響用戶隱私和安全範圍，所以這一步是必要流程，條款可以收合或提供外部連結，但不建議預先幫用戶勾選同意。
後續隱私條款更新，若要用信件通知的方式取代重複簽署條款，需在用戶簽署條款時就附加這條內容，實際作法仍需考量各國法規及企業決策。
2–2 帳號關聯的流程
SSO 的會員只會有一個使用者 ID（User ID），一個 User ID 可對應多組帳號（Account），是 SSO 與各服務間辨識用戶的重要資訊。但是用戶端無法得知或記得，因此，系統需要一個用戶自己知道且不會輕易變更的資訊，做為關聯帳號的判斷資料，例如：手機號碼、身分證號碼、護照號碼等。
判斷帳號為同一用戶的流程中，需提供清楚的操作說明，例如「整併」或「關聯」按鈕，以確保用戶了解自己正在進行的操作。
無論選擇哪種方式關聯帳號，請妥善處理和保護任何敏感資訊，並設計相對應的替換流程。 以手機號碼舉例，需設計用戶自行更換手機的機制，當手機號碼已被使用時，後台也需具備協助更換手機的功能。
2–3 使用第三方登入 SSO
開放第三方登入（社群登入），不需要重複輸入帳號密碼，可以減少使用者的登入成本，提升用戶體驗。雖然社群登入對使用者來說很方便，但在高度要求安全的企業系統中，應謹慎使用，因為攻擊者有機會從社交媒體平台竊取用戶信息，進而登入企業系統造成安全風險。
如果你的應用程式在 Apple Store 上架，需特別注意 Apple 的上架規範，使用第三方登入時，需具備 Sign in with Apple 的選項（Apple ID）。（企業內部及教育應用程式除外，詳情請看 App Store Review Guidelines）
2–4 刪除帳號機制
服務為了保留用戶，會將刪除帳號的功能隱藏起來，用戶需聯繫客服才能刪除帳號，2022 年開始規定上架 App Store 的應用程式，皆需在介面上提供用戶刪除帳號的功能。
刪除帳號分為「刪除單一服務」和「刪除 SSO 帳號」，刪除單一服務時，後台需設計隱碼機制，被刪除的服務端登入後台系統時，不能看到的資訊需隱碼。舉例來說姓名顯示 王XX，性別、手機、生日、Email 使用 - 或是 NA 代替。
Apple 於 2022 年規範提交至 App Store 的 App 需提供帳戶刪除選項。
詳情請參考 Apple Developer- 刪除單一服務：意味服務條款已刪除，但不會影響該帳號其他服務，User ID 不變，用戶可重新註冊該服務。
- 刪除 SSO 帳號：帳號去識別化，並帳號資料清除（手機 / 第三方登入 Token），原本的手機號碼跟第三方登入可以重新註冊為新的會員帳號（新的 User ID）
三、設計要點
導入 SSO 到既有服務時，需要了解現有系統的限制和複雜性，可能會遇到其他特殊情境和做法，專案的過程發生各式各樣狀況，例如：串接方沒有工程師或設計師、外包商已結案、串接方不想動既有程式碼（不小心描述得太寫實😅）
儘管有各種不可控的因素，設計師在實務上仍然有可著墨的地方：
3–1 理解 SSO 流程及限制
了解 SSO 的基礎知識，以及各個服務的限制，並確保 SSO 在現有的應用程式上實現無縫的使用者體驗，繪製流程圖可以幫助各個角色理解及溝通 SSO 的流程。
3–2 提供標準的流程及回饋
儘管你可能無法控制其它應用程式怎麼設計，但是你可以提供標準作法，讓其他服務參考，提升易用性的設計技巧，例如：
- 提供整併過程的詳細說明，包括可能的結果和影響範圍，以確保用戶明白他們在做什麼。
- 通知用戶整併帳戶的結果（成功/錯誤），以及如何使用新整併的會員帳戶。
- 為流程轉換之間未知的錯誤，設計錯誤狀態，例如：404、維護模式、Something Went Worng…
