SSO方案中太多平行对称的分支选择,就像博而赫斯那小径分岔的花园。刚手写完一个超迷你劲袖珍的SSO,顺着 SAML2.0和OpenID的规范,记录一下这些分岔点:

  1. 流程是从身份提供者还是消费者发起?
    身份提供者,也就是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的存在。
  2. URL参数中传送身份信息还是仅仅是指针
    SSO Server 向 Client跳转时,可以大大方方的把身份信息放在URL参数里直接传输,也可以小心翼翼的只扔过来一个随机字符串(SAML中叫 Artifact),Client拿着这个随机字串再到后台偷偷摸摸用WebService/REST接口问SSO Server拿到完整的身份信息。
    显然,前一种方式少了一次后台查询,速度更快,但没有后一种方式安全,后一种方式的WebService/REST接口还可传输任意格式的很多很多的信息。
  3. 安全措施是全文加密还是仅仅签名
    有人喜欢全文(再加一个nonce)加密成长长一段密文,心中充满了安全感。也有人大胆的明文传输内容,只在最后加个签名来防伪(签名用简单的明文+密钥散列,或者HMAC加密散列算法)
    前者用户只看到长长一段火星文,不会让用户偷窥到什么,但字串暴长且加解密本身比较消耗CPU。
  4. SSO Client会自己解密/比对签名吗?
    一般,SSO Client会根据约定自己解密或根据明文生成签名进行比对,还要负责验证那个nonce不会已被使用或者已经超时等等。
    但也会可以有很懒的client,不懂这么复杂的安全加密算法,直接把收到的内容在后台用WebService/Rest接口发回给SSO Server帮忙搞定。



    刚刚手写那个SSO,身份提供者发起流程,在URL参数中传输加密的身份信息,由SSO Client自行解密,so,超简单...