单点登录(SSO)是什么?

93 阅读8分钟

1. 什么时单点登录

单点登录(Single Sign On),简称为 SSO,是目前比较流行的企业业务整合的解决方案之一。SSO 的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。

3.2. 单点登录概念

单点登录分为多个系统和一个认证系统 SSO,如图:

image.png

图中有4个系统,分别是 Application1、Application2、Application3 和 SSO。Application1、Application2、Application3 没有登录模块,而 SSO 只有登录模块,没有其他的业务模块,当 Application1、Application2、Application3 需要登陆时,将跳到 SSO 系统,SSO 系统完成登录,其他的应用系统也就随之登录了。

3. 同域下的单点登录

利用 cookie 可以设置二级域名的特点达到 cookie 共享的目的。

例如此时有三个域名:app1.a.com、app2.a.com、sso.a.com。

当用户在 app1.a.com 系统中的 session 中查找不到时,因为之前登录会在 sso.a.com 中设置二级域名的 cookie(在这里时 .a.com),所以 app1.a.com 的请求就可以拿到该 cookie,接着用该 cookie 请求 sso.a.com 的接口,sso.a.com 系统拿到 cookie 后会在自己的 session 中查找是否存在,存在则返回 session 给 app1.a.com 系统同步,否则让用户跳转到 sso.a.com 系统进行登录。

4. 不同域下的单点登录

不同域下的单点登录参考 CAS 官网上的标准流程,具体流程如下:

  1. 用户访问 app 系统,app 系统是需要登录的,但用户现在没有登录。
  2. 跳转到 SSO 登录系统,SSO 系统也没有登录,弹出用户登录页。
  3. 用户填写用户名、密码,SSO 系统进行认证后,将登录状态写入 SSO 的 session,浏览器(Browser)中写入 SSO 域下的 Cookie。
  4. SSO 系统登录完成后会生成一个 ST(Service Ticket),然后跳转到 app 系统,同时将 ST 作为参数传递给 app 系统。
  5. app 系统拿到 ST 后,从后台向 SSO 发送请求,验证 ST 是否有效。
  6. 验证通过后,app 系统将登录状态写入 session 并设置 app 域下的 Cookie。

至此,跨域单点登录就完成了。以后我们再访问 app 系统时,app 就是登录的。接下来,我们再看看访问 app2 系统时的流程。用户访问 app2 系统,app2 系统没有登录,跳转到 SSO。

  1. 由于 SSO 已经登录了,不需要重新登录认证。
  2. SSO 生成 ST,浏览器跳转到 app2 系统,并将 ST 作为参数传递给 app2。
  3. app2 拿到 ST,后台访问 SSO,验证 ST 是否有效。
  4. 验证成功后,app2 将登录状态写入 session,并在 app2 域下写入 Cookie。

这样,app2 系统不需要走登录流程,就已经是登陆了。SSO,app 和 app2 在不同的域,它们之间的 session 不共享也是没问题的。

参考链接:

单点登录(SSO)看这一篇就够了-阿里云开发者社区

5. 单点登录系统,如果 cookie 禁用,怎么解决?

如果禁用 cookie 可以使用 url 中带参数,把 token 传递给服务端。

当然此方法涉及安全性问题,其实在 cookie 中保存 token 同样存在安全性问题。推荐使用 sso 框架 CAS 实现单点登录。

6. SSO 原理(单点登录的过程)

以登录天猫为例进行说明:

  • 当用户第一次访问淘宝的时候,因为还没有登录,会被引导到认证中心进行登录。
  • 根据用户提供的登录信息,认证系统进行身份验证,如果通过,则登录成功,并返回给用户一个认证的凭据(JWT token)。
  • 当用户访问天猫时,就会将这个 JWT token 带上,作为自己认证的凭据。
  • 应用系统接收到请求后会把 JWT token 送到认证中心进行校验。
  • 如果通过校验,用户就可以在不用再次登录的情况下访问天猫了。

7. 什么是 CAS?

CAS 框架:CAS(Central Authentication Service,即:统一认证服务)是实现 SSO 单点登录的框架。

CAS 分为两部分:

  1. CAS Server
  2. CAS Client

CAS Server 用来负责用户的认证工作,就像是把第一次登录用户的一个标识存在这里,以便此用户在其他系统登录时验证其需不需要再次登录。

CAS Client 就是我们自己开发的应用程序,需要接入 CAS Server 端。当用户访问我们的应用时,首先需要重定向到 CAS Server 端进行验证,要是原来登陆过,就免去登录,重定向到下游系统,否则进行用户名密码登录操作。

8. CAS 中 3 个术语?

Ticket Granting ticket(TGT):可以认为是 CAS Server 根据用户名密码生成的一张票,存在 Server 端

Ticket-granting cookie(TGC):其实就是一个 Cookie,存放用户身份信息,由 Server 发给 Client 端

Service ticket(ST):由 TGT 生成的一次性票据,用于验证,只能用一次。相当于 Server 发给 Client 一张票,然后 Client 拿着这个票再来找 Server 验证,看看是不是 Server 签发的。

9. CAS 处理流程?

  1. 用户访问网站,第一次来,重定向到 CAS Server,发现没有 cookie,所以再重定向到 CAS Server 端的登录页面,并且 URL 带有网站地址,便于认证成功后跳转,例如 http ?/cas-server:8100/login?service=http ?/localhost:8081

注意:service 后面这个地址就是登录成功后要重定向的下游系统 URL。

  1. 在登录页面输入用户名密码认证,认证成功后 cas-server 生成 TGT,再用 TGT 生成一个 ST。然后再第三次重定向并返回 ST 和 cookie(TGC)到浏览器
  2. 浏览器带着 ST 再访问想要访问的地址

http ?/localhost:8081/?ticket=ST-25939-sqbDVZcuSvrvBC6MQlg5

注意:ticket 后面那一串就是 ST

  1. 浏览器的服务器收到 ST 后 再去 cas-server 验证以下是否为自己签发的,验证通过后就会显示页面信息,也就是重定向到第1步 service 后面的那个 URL

首次登录完毕。

  1. 再登录另一个接入 CAS 的网站,重定向到 CAS Server,server 判断是第一次来(但是此时有 TGC,也就是 cookie,所以不用去登录页面了),但此时没有 ST,去 cas-server 申请一个于是重定向到 cas-server,形如:http://cas-server:8100/login?service=http?/localhost:8082 && TGC(cookie)(传目标地址和 cookie)
  2. cas-server 生成了 ST 后重定向到浏览器 http ?/localhost:8082/?ticket=ST-25939-sqfsafgefesaedswqqw5-xxxx
  3. 浏览器的服务器收到 ST 后再去 cas-server 验证一下是否为自己签发的,验证通过后就会显示页面信息(同第4步)

10. 什么是 Token?

Token 的意思是“令牌”,是服务端生成的一串字符串,作为客户端进行的请求的一个标识。

当用户第一次登陆后,服务器生成一个token并将此token返回给客户端,以后客户端只需带上这个token前来请求数据即可,无需再次带上用户名和密码。

简单Token的组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名,token的前几位以哈希算法压缩成的一定长度的十六进制字符串。为防止token泄露)。

11. OAuth 是什么?

OAuth 是一个行业的标准授权协议,主要用来授权第三方应用获取有限的权限。实际上它就是一种授权机制,最终目的是为第三方应用颁发一个有时效性令牌 token,使得第三方应用能够通过该令牌获取相关的资源。

OAuth 2.0 比较常用的场景就是第三方登录,当你的网站接入了第三方登录时一般就是使用的 OAuth 2.0 协议。

现在 OAuth 2.0 也常见于支付场景(微信支付、支付宝支付)和开发平台(微信开放平台、阿里开放平台等等)。

12. 介绍下 Access Token?

Access Token 是在 Oauth2.0 协议中,客户端访问资源服务器时需要带上的令牌(其实就是一段全局唯一的随机字符串)。拥有这个令牌代表着得到用户的授权。令牌里面包含哪个用户 在什么时候 授权给哪个 app 去做什么事情。当然这些信息是不能直接从 Access Token 看出来的,而是存在平台方的数据库中,平台可以用 Access Token 作为 key 去查询出这些信息,然后验证调用方是否有权限。

13. 介绍下 Refresh Token?

Refresh Token 是专用于刷新 Access Token 的 token。如果没有 Refresh Token,也可以刷新 Access Token,但每次刷新都要用户输入登录用户名与密码。有了 Refresh Token,客户端直接用 Refresh Token 去更新 Access Token,无需用户进行额外的操作。

14. 介绍下 JWT ?

Json Web Token(JWT)是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准。该 token 被设计为紧凑且安全,特别适用于分布式站点单点登录场景。

JWT 由头部(header)、载荷(payload)、签证(signature)三部分组成。