SSO中的Pattern
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，超简单...