SSO方案中太多平行對稱的分支選擇，就像博而赫斯那小徑分岔的花園。剛手寫完一個超迷你勁袖珍的SSO，順著 SAML2.0和OpenID的規范，記錄一下這些分岔點：
- 流程是從身份提供者還是消費者發起？
身份提供者，也就是SSO Server了，又叫Id Provider，簡稱Idp。而身份消費者，SSO Client，在SAML里叫做Sp。
身份提供者發起流程中，用戶登錄進SSO Server，SSO Server展現一個Portal/菜單，上有到各SSO Client的URL若干，每個URL上都已經加了身份信息的料。
身份消費者發起流程中，Portal/菜單里是無料的普通URL(甚至用戶直接就先跑去了Client的網站)，SSO Client發現本地Session里沒有用戶的身份信息，只好redirect重返SSO Server，最后Server再以有料的URL跳轉回去。
顯然，前一種流程少了兩次Redirect，速度更快，但Portal/菜單中的每個URL都深深的耦合著SSO Sever，又或者，有時根本就沒有這么一個中央Portal的存在。
- URL參數中傳送身份信息還是僅僅是指針？
SSO Server 向
Client跳轉時，可以大大方方的把身份信息放在URL參數里直接傳輸，也可以小心翼翼的只扔過來一個隨機字符串(SAML中叫
Artifact)，Client拿著這個隨機字串再到后臺偷偷摸摸用WebService/REST接口問SSO Server拿到完整的身份信息。
顯然，前一種方式少了一次后臺查詢，速度更快，但沒有后一種方式安全，后一種方式的WebService/REST接口還可傳輸任意格式的很多很多的信息。
- 安全措施是全文加密還是僅僅簽名？
有人喜歡全文(再加一個nonce)加密成長長一段密文，心中充滿了安全感。也有人大膽的明文傳輸內容，只在最后加個簽名來防偽(簽名用簡單的明文+密鑰散列，或者HMAC加密散列算法)
前者用戶只看到長長一段火星文，不會讓用戶偷窺到什么，但字串暴長且加解密本身比較消耗CPU。
- SSO Client會自己解密/比對簽名嗎？
一般，SSO Client會根據約定自己解密或根據明文生成簽名進行比對，還要負責驗證那個nonce不會已被使用或者已經超時等等。
但也會可以有很懶的client，不懂這么復雜的安全加密算法，直接把收到的內容在后臺用WebService/Rest接口發回給SSO Server幫忙搞定。
剛剛手寫那個SSO，身份提供者發起流程，在URL參數中傳輸加密的身份信息，由SSO Client自行解密，so，超簡單...