本文是个人学习的记录，系列文章
传统的登录，就是根据用户名，密码，建立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。
后记
- Resource Owner Password Credentials Grant （资源所有者密码凭据许可）
- Implicit Grant （隐式许可）
- Authorization Code Grant （授权码许可）
- Client Credentials
参考
码农翻身
