单点登录SSO
借助阿里云的应用身份服务
什么是登录
一、（session&cookie模式）
1、用户向服务器发送用户名和密码。
2、服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。
3、服务器向用户返回一个 session_id，写入用户的 Cookie。
4、用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。
5、服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。
服务器保存session 客服端浏览器cookie一般存了个jsessionid的值，后面浏览器每次提交会自动带上该值
二、JWT(json web token)模式
JWT头部 JWT有效载体 JWT签名
JWT头部 {"alg": "HS256","typ": "JWT"} base64: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
JWT有效载体 { "sub": "1234567890", "name": "John Doe", "admin": true } base64:eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
JWT签名 HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) base64:TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
JWT完整字符串：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
使用一般是请求头里加入Authorization，并加上Bearer标注。
Authorization: Bearer <token>
JWT有效载体中官方规定的7各字段
iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号
单点登录
系统1：www.abc.com 系统2：www.def.com 系统3（SSO）：www.sso.com
1:访问www.abc.com由于没有登录访问www.sso.com?service=www.abc.com
2:由于www.sso.com没有登录，提升用户输入用户名密码登录。
3:用户与SSO系统建立会话（生成一份Token，写到Cookie中，保存在浏览器上）
4:随后SSO重定向回系统ABC，并把Token携带过去给系统ABC，重定向的地址如下：www.abc.com?token=xxxxxxx
5:系统ABC收到token后，通过后端向SSO验证token是否正确，如果正确系统ABC与用户建立局部会话（创建Session）
6:此时，用户想要访问系统DEF发现便没有登录这跳转到www.sso.com?service=www.def.com
7:因为用户与SSO系统建立了全局会话，访问www.sso.com?service=www.def.com时会带上cookie，
8:这时SSO系统已经登录，于是在重定向系统DEF, www.def.com?token= xxxxxxx
9:同样系统DEF收到token后，通过后端向SSO验证token是否正确，如果正确系统DEF与用户建立局部会话（创建Session）
一、cookie实现（必须统一域名，未来不可用苹果浏览器开发封杀chrome和firefox已经开始了）
app1.a.com app2.a.com sso.a.com
登录OSS.a.com是把cookie写在a.com域下，这样app1, app2都在该域下。通用了cookie
二、Jsonp和页面重定向技术
CAS：
一、我们看看访问app1系统时的流程
1：用户访问app1系统，app1系统是需要登录的，但用户现在没有登录。
2：跳转到CAS server，即SSO登录系统，以后图中的CAS Server我们统一叫做SSO系统。 SSO系统也没有登录，弹出用户登录页。
3：用户填写用户名、密码，SSO系统进行认证后，将登录状态写入SSO的session，浏览器（Browser）中写入SSO域下的Cookie。
4：SSO系统登录完成后会生成一个ST（Service Ticket），然后跳转到app1系统，同时将ST作为参数传递给app系统。
5：app1系统拿到ST后，从后台向SSO发送请求，验证ST是否有效。
6：验证通过后，app1系统将登录状态写入session并设置app域下的Cookie。
至此，跨域单点登录就完成了。以后我们再访问app1系统时，app1就是登录的。
二、接下来，我们再看看访问app2系统时的流程。
1：用户访问app2系统，app2系统没有登录，跳转到SSO。
2：由于SSO已经登录了，不需要重新登录认证。
3：SSO生成ST，浏览器跳转到app2系统，并将ST作为参数传递给app2。
4：app2拿到ST，后台访问SSO，验证ST是否有效。
5：验证成功后，app2将登录状态写入session，并在app2域下写入Cookie。
这样，app2系统不需要走登录流程，就已经是登录了。SSO，app和app2在不同的域，它们之间的session不共享也是没问题的。
OAuth2.0
各种第三方登录QQ登录，微信登录，一般都是使用标准的OAuth2.0
接入过第方登录的就知道，要有APP_ID 和APP_SECRET 主要包括（应用ID，应用名称，应用SECRET，和跳转地址）
1: 从信任角度来看。OAuth2.0授权服务端和第三方客户端不属于一个互相信任的应用群（通常都不是同一个公司提供的服务），第三方客户端的用户不属于OAuth2.0授权服务端的官方用户；而单点登录的服务端和接入的客户端都在一个互相信任的应用群（通常是同一个公司提供的服务），各个子系统的用户属于单点登录服务端的官方用户。
2: 从资源角度来看。OAuth2.0授权主要是让用户自行决定——“我”在OAuth2.0服务提供方的个人资源是否允许第三方应用访问；而单点登录的资源都在客户端这边，单点登录的服务端主要用于登录，以及管理用户在各个子系统的权限信息。
3: 从流程角度来看。OAuth2.0授权的时候，第三方客户端需要拿预先“商量”好的密码去获取Access Token；而单点登录则不需要。
以上是 单点登录SSO 的全部内容， 来源链接： utcz.com/z/516689.html
