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