web安全基础知识之单点登录-SSO几种原理图解（single sign on）

本文是个人学习的记录，系列文章

传统的登录，就是根据用户名，密码，建立session，把session通过cookie发送到请求者的浏览器上，下次在登陆会发送cookie，这样服务器就知道登录了。

SSO：单点登录，

在一个地方登录一次，就可以访问所以的系统

1.cookie（不能跨域

2.session（共享session，在不同是系统，不同架构下的session共享麻烦

3.使用token

利用cookie，在用户登录后，在cookie中写入token，在用户访问其他系统的时候，验证一下token，如果没有问题，就认为用户已登录。

JWT（JSON Web Token)加密的token，防止篡改。加密通过hash算法将密钥生成签名。这个签名也是数据的一部分，会传输到系统中去。

其他的系统，用相同的算法计算签名，然后再和计算的签名对比，如果相等，就证明已经登录。如果不相等则作其他处理。

上面存在算法，密钥一致性的问题，同时密钥分发也存在问题。

SSO认证中心

1.建立一个session

2.创建一个ticket（可以认为是一个随机字符串）

3.重定向到认证中心，URL中附带着ticket ‘www.a.com/pageA?ticket=T123’,同时cookie也会被发到浏览器，比如Set Cookie: ssoid=1234;domain=sso.com.

其他系统拿到ticket后，需要再次向认证中心进行验证

若此时再访问其他页面，不需要去认证中心登陆。在前面服务器给浏览器发送给自己的cookie，到时候浏览器自然会带过来，就知道用户已登录。

再登陆一个其他系统时

系统B验证Ticket

耶鲁大学提出来的CAS（Central Authentication Service），一个著名的SSO解决方案

Token

系统在前端调用第三方网站的权限认证系统时，流程如下：

在上面的第六步中，通过重定向把这个Token以明文的方式发送到浏览器，虽然是HTTPS，不会中途被人窃取，但是在浏览器历史记录或者访问日志能够找到。也不安全。

授权码+Token

在与第三方系统完成登录认证后，将授权码通过一个Authorization Code的中间层，在后台访问第三方的认证中心，才发真正的token。

本质上就是将返回的授权码在服务器后台，完成申请Token的过程，浏览器端接触不到token。

隐藏token，但是授权码暴露了，但是在向第三方系统申请时app_id,app_secret相关联，只有自己系统发出的token才认为是合法的。同时可以设置时间限制，让授权码只能更换一次token。

后记

1. Resource Owner Password Credentials Grant （资源所有者密码凭据许可）
2. Implicit Grant （隐式许可）
3. Authorization Code Grant （授权码许可）
4. Client Credentials

参考

码农翻身