sso方案中太多平行对称的分支选择，就像博而赫斯那小径分岔的花园。刚手写完一个超迷你劲袖珍的sso，顺着 saml2.0和openid的规范，记录一下这些分岔点：
- 流程是从身份提供者还是消费者发起？
身份提供者，也就是sso server了，又叫id provider，简称idp。而身份消费者，sso client，在saml里叫做sp。
身份提供者发起流程中，用户登录进sso server，sso server展现一个portal/菜单，上有到各sso client的url若干，每个url上都已经加了身份信息的料。
身份消费者发起流程中，portal/菜单里是无料的普通，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，超简单...