ElMO

前些陣子因為某個客戶家的 Single Sign-on(SSO) 流程亂寫，導致登入機制被繞過

在和客戶來回時突然想到一個現實情境可以解釋 Single sign-on 的流程

簡介 Single sign-on

Single sign-on 誕生的原因，我們先將世界觀縮小至一個企業，假如此企業有許多網站（官網、商城、論壇...），如果每一個站都要分別註冊，在帳密管理上麻煩且容易混亂，因而誕生了 Single sign-on（接下來簡稱 SSO）。

Single sign-on 流程

使用 SSO 在登入時，除了使用者及欲登入的網站，還會多一個授權中心的角色。

SSO 的安全性建立在所有網站信任授權中心認證後的身份，實作上若依照基本相互驗證的流程做完，就會有安全性疑慮。

以下為使用者欲登入網站時，SSO 做身份驗證的流程：

1. 使用者在網站上點選登入
2. 網站將使用者重導至授權中心
3. 身份驗證：使用者於授權中心進行登入動作，並登入成功
4. 授權中心於確認身份後，派送一張 ticket 給使用者，並重導回網站
5. 網站收到使用者的 ticket 後，向授權中心驗證這張 ticket
6. 驗證成功，網站派發 session 給使用者並登入

換個故事說

2020 年因為疫情延燒，導致無論去哪都要實名制

1. 今天 A 同學要去遊樂園玩，他到剪票口，表示想入園遊玩
2. 剪票口的人請 A 同學先去旁邊的小房間填寫實名制表單
3. A 同學在填寫表單，小房間的人將資料登記
4. 小房間的人給 A 同學一張印有自己身份證字號的單子，請 A 同學拿著單子去剪票口
5. 剪票口的人收到單子，打電話去小房間，確認單子上的身份
6. 確認無誤後，把單子銷毀，並給 A 同學一張門票，A 同學入園

最後

2020 年因為疫在做身份鑑別的過程中，雙向驗證是很重要的環節，假設在第 5 步驟，剪票口沒有去向小房間確認單子上的資訊（網站沒有向授權中心驗證 ticket），那麼 A 同學如果在從小房間到剪票口的路途中偷天換日（使用者如果在重導回網站的過程中更改 ticket 內容），也不會被察覺。