浅析即时通讯开发前置 HTTP SSO 单点登陆接口的原理

Posted 2022-08-13 wecloud1314

一个安全的信息系统，合法身份检查是必须环节。尤其 IM 这种以 “人” 为中心的社交体系，身份认证更是必不可少。

一些 PC 时代小型 IM 系统中，身份认证可能直接做到长连接中（也就是整个 IM 系统都是以长连接为中心：身份鉴权、数据收发、文件传送等等）。但当前主流的 IM（尤其新一代的移动端 IM）中，都是 “长”（指 TCP 或 UDP 长连接）、“短”（是指 Http 短连接）相结合的方式。

 

一个现代的移动端 IM “长”、“短” 连接配合内容大致如下：

    1）短连接用途 1：前置 HTTP 的 SSO 单点接口来实现身份认证；

    2）短连接用途 2：集群式的 IM 中可能还会有独立（或集成于 SSO 单独登陆接口中）的 SLB 接口（即基于 HTTP 短连接拉取 IM 服务器集群 IP 列表）；

    3）短连接用途 3：各种小文件的上传、下载接口实现（头像、图片、语音、文件等）都会是基于 Http 实现；

    4）长连接用途 1：用户的实时上、下线状态通知；

    5）长连接用途 2：实时的加友、加群等指令收发；

    6）长连接用途 3：服务端发起的其它实时指令推送等。

总之：当今主流的移动 IM 系统中，“长”、“短” 连接分工明确，各自将自身的优势发挥到最大化，优点是：系统分工明确、分层清晰、业务划分合理、负载方案成本低、符合移动网络的特性等。

针对上述主流移动 IM 系统中 “长”、“短” 连接的分工方式，其中最为重要也是用户最先接触到的 —— 就是基于 Http 的 SSO 单点登陆接口（有的系统里可能并不叫 SSO 接口，本文讨论的是其广义：即实现身份认证功能的 http 接口），那么这个 SSO 接口工作原理是什么？可以怎么来实现？有无最佳实践建议？

假设一个场景：公司内部有财务、OA、订单服务等各类相互独立的应用系统，员工张三对这些系统有操作权限，如果张三想要登录某个系统进行业务操作，那么他需要输入相应的账号与密码。

想象一下：当公司内部有 100 个应用系统，张三是不是要输入 100 次用户名和密码进行登录，然后分别才能进行业务操作呢？显然这是很不好的体验。

因此我们需要引入一个这样的机制：张三只要输入一次用户名和密码登录，成功登录后，他就可以访问财务系统、OA 系统、订单服务等系统 —— 这就是单点登录。

单点登录的英文全称是 Single Sign On，简称是 SSO：

它的意思是说用户只需要登录一次，就可以在个人权限范围内，访问所有相互信任应用的功能模块，不管整个应用群的内部有多么复杂，对用户而言，都是一个统一的整体。用户访问 Web 系统的整个应用群与访问单个系统一样，登录和注销分别只要一次就够了。

举个简单的例子，你登录了百度网页之后，点击跳转到百度贴吧，这时可以发现你已经自动登录了百度贴吧 —— 这就是单独登陆的原理。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

 

针对本文上半部分的原理介绍，我们以一个真实的信息系统为例，理论联系实际来讲解具体的 SSO 单点登陆技术实现（实际上，用 IM 系统的设计思路来看这个例子，可能有点复杂，但知识是相通的，它更有助于对 SSO 完整知识体系的理解。）

SSO 的技术实现要想做好并不容易，作者认为需求优先级应该先是单点登录和单点注销功能，然后是应用接入的门槛，最后是数据安全性，安全性对于 SSO 也非常重要。SSO 的核心是认证中心，但要实现用户一次登录，到处访问的效果，技术实现需要建立在用户系统、认证中心、权限系统、企业门户的基础上。

各职责如下：

用户系统：负责用户名、密码等帐户信息管理，包括增加、修改、启用、停用用户帐号，同时为认证中心提供对用户名和密码的校验；

认证中心：负责凭证 token 的生成、加密、颁发、验证、销毁、登入 Login、登出 Logout。用户只有拥有凭证并验证通过才能访问企业门户；

权限系统：负责角色管理、资源设置、授权设置、鉴定权限，具体实现可参考 RBAC。权限系统可为企业门户提供用户权限范围内的导航；

企业门户：作为应用系统的集成门户 (Portal)，集成了多个应用系统的功能，为用户提供链接导航、用户信息和登出功能等。

主要包含以下内容：

登录认证：接收登录帐号信息，让用户系统验证用户的登录信息；

凭证生成：创建授权凭证 token，生成的凭证一般包含用户帐号信息、过期时间等信息，它是一串加密的字符串，加密算法如 AES｛凭证明文 +MD5 加信息｝，可采用 JWT 标准；

凭证颁发：与 SSO 客户端通信，发送凭证给 SSO 客户端；

凭证验证：接收并校验来自 SSO 客户端的凭证有效性，凭证验证包括算法验证和数据验证；

凭证销毁与登出：接收来自 SSO 客户端的登出请求，记录并销毁凭证，跳转至登录页面。

客户端的实现逻辑大致如下：

1）请求拦截：拦截应用未登录请求，跳转至登录页面；

2）获取凭证：接收并存储由 SSO 服务端发来的凭证，凭证存储的方式有 Cookie、Session、网址传参、Header 等；

3）提交凭证验证：与 SSO 服务端通信，发出校验凭证有效性的请求；

4）获取用户权限：获取该凭证的用户权限，并返回受保护资源给用户；

5）凭证销毁与登出：销毁本地会话，然后跳转至登出页面。

用户的单点登录流程如下：

1）登录：将用户输入的用户名和密码发送至认证中心，然后认证中心调用用户系统来验证登录信息；

2）生成并颁发凭证：通过登录信息的验证后，认证中心创建授权凭证 token，然后把这个授权凭证 token 返回给 SSO 客户端。SSO 客户端拿到这个 token，进行存储。在后续请求中，在 HTTP 请求数据中都得加上这个 token；

3）凭证验证：SSO 客户端发送凭证 token 给认证中心，认证中心校验这个 token 的有效性。凭证验证有算法验证和数据验证，算法验证可在 SSO 客户端完成。

例子中的应用接入与集成具体如下：

1）用户系统：接入国内机票平台的用户系统，负责登录认证；

2）权限系统：接入国内机票平台的权限系统；

3）认证中心：负责生成并颁发凭证、销毁凭证，改造国内机票平台的登入、登出；

4）凭证验证：在国内机票、国际机票应用系统中调用 SSO 客户端组件实现凭证的验证；

5）企业门户：由国内机票平台、国际机票平台承担。