单点登录的6种主要技术和特点：现在用得比较多的单点登录技术是什么

单点登录的6种主要技术和特点：现在用得比较多的单点登录技术是什么顾名思义，多个应用系统在同一个地方进行认证。这样每个人用一个账号就可以登录多个系统。多个系统实现单点登录后，会有以下的效果：单点登录是一个身份验证机制，英文全称 Single Sign On，简称 SSO。它的定义是：在多个应用系统中，用户只需要登录一次，即可访问所有相互信任的应用系统，就像健康保一样，为你的身份做担保。3. 不同应用和员工数据之间割裂，不同设备和操作系统不兼容。4. 不同应用、各地分支机构，档案信息不同。单点登录可以解决这些痛点。

单点登录

假如你是企业管理者，你的公司正在使用包括考勤系统、差旅报销系统、在线协同工具等十几甚至几十套不同的软件系统，你的员工是否可以在这些不同的系统中，一次登录全部搞定？有没有发生多人共享同一账号，造成身份管理混乱的情况？

企业在统一员工身份管理时，面临诸多挑战：

1. 应用太多，员工账号密码众多，复杂难记，或设置单一，存在安全隐患。

2. 登录入口众多，没有统一界面，切换频繁，体验差。

3. 不同应用和员工数据之间割裂，不同设备和操作系统不兼容。

4. 不同应用、各地分支机构，档案信息不同。

单点登录可以解决这些痛点。

单点登录是一个身份验证机制，英文全称 Single Sign On，简称 SSO。它的定义是：在多个应用系统中，用户只需要登录一次，即可访问所有相互信任的应用系统，就像健康保一样，为你的身份做担保。

顾名思义，多个应用系统在同一个地方进行认证。这样每个人用一个账号就可以登录多个系统。多个系统实现单点登录后，会有以下的效果：

1. 在任何一个系统登录后，再访问其他系统，不必再次输入密码进行认证。至于需不需要再点一次登录按钮，取决于业务系统，不取决于中央认证服务器。
2. 在任何一个系统登出后，是否从其他系统退出，是否从中央认证服务器退出，也取决于场景和实现。

解决唯一可信数据源的问题

单点登录需要具备一份唯一可信的用户目录，全部系统都在中央认证服务器完成认证，信赖中央认证服务器返回的身份信息。这可以实现一个账号登录多个系统的效果。

建议使用 OIDC 协议作为单点认证的身份协议，有以下好处：

1. 无需进行字段对齐，协议规定了字段标准
2. 轻量、安全，OIDC 是 OAuth 2.0 的超集，学习成本低

解决子系统之间登录态问题

为了让子系统之间能够互相识别出登录态，需要额外的工作。常用的方式一般有共享 cookie，跨域发送 Cookie 查验登录态，静默检测中央认证服务登录态。

共享 Cookie

如果两个系统在同一个主域名下，可以通过在根域名写 Cookie 的方式来共享登录状态。

跨域发送 Cookie 查验登录态

子系统可以跨域发送中央认证服务器的 Cookie 到中央认证服务器来检验用户是否已经登录，需要中央认证服务器的支持。

静默检测中央认证服务器登录态

在访问每个系统时，先到中央认证服务器检测登录态，可以在一个隐藏的 iframe 里面向 OIDC 服务发起登录请求，prompt=none 参数为静默登录。如果用户曾经在其他系统登录成功，当前系统会收到该用户的 token，当前业务系统在用户无法察觉的情况下与浏览器建立会话，完成登录；如果用户没有登录，当前系统应该将用户转到中央认证服务器，让用户完成认证，然后与用户建立会话。

登出

用户在一个业务系统登出后，业务系统可以通知中央认证服务器，退出用户与中央认证服务器的登录状态，通知其他业务系统，将用户退出。也可以不进行通知，用户可以继续浏览其他系统。

单点登录主要实现方式有三种：

方式 1：通过 session 进行验证

session 称为“会话”，session 对象存储特定用户会话所需的属性及配置信息。简言之，session 就是服务器为了储存用户信息而创建的一个验证手段。用户在登录了一个系统后，服务器会将登录信息储存在一个 session 中，产生 session ID，客户端会保存该 ID；当这个用户再登录其他系统时，服务器会自动复制上一个模块的 session 到该服务器的 session 中，以获取用户登录信息，实现用户只登录一次，就可以登录其他系统。在用户退出登录时，服务器会自动删除 session。整个过程均在服务器端完成，用户实际使用时没有感知。

方式 2：通过 cookie 进行验证

cookie 是某些网站为了辨别用户身份，由服务端生成，发给客户端暂时或永久保存的信息。简言之，cookie 就是一种存储用户数据的媒介。举例来说，当我们打开一个网站，比如新浪、CSDN、知乎时，输入用户名和密码登录后系统会默认存储这些信息，在下一次登录时，就不需要再次输入用户名和密码，而是默认直接登录，进入页面。

方式 3：通过 token 进行验证

token 在身份认证中是令牌的意思，在词法分析中是标记的意思。一般作为邀请、登录系统使用。简言之，token 就是一种凭证，用户在登录注册时需要获取凭证，在经过验证后，方可登录相关被授权的应用。用户在首次登录系统时输入账号和密码，服务器会收到登录请求，然后验证是否正确；服务器会根据用户信息，如用户 ID、用户名、密钥、过期时间等信息生成一个 token 签名，然后发给用户；用户验证成功后，返回 token；前端服务器收到 token 后，存储到 cookie 或 Local Storage 里；当用户再次登录时，会被服务器验证 token；服务器收到用户登录请求后，对 token 签名进行比对：如果 token 验证正确，用户登录成功；如果 token 验证不正确，用户登录失败，跳转到登录页。

session 与cookie、token 验证的区别

_	session	cookie	token
存储端	服务器	客户端（比如浏览器）	客户端
存储量	不限，当访问增多时，速度下降	不超过 4KB，每个浏览器最多 20 个	由开发者设定
安全性	比 cookie 安全性高，篡改者只能看到session_id，看不到其他信息	不安全，本地 cookie 易被盗取，篡改者可以看到该字段所有信息	安全，服务端会加密生成的令牌，存在客户端

JWT Token

JSON web token (JWT) 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准（(RFC 7519)。该 token 被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

认证流程

用户认证的流程

• 用户使用账号（手机/邮箱/用户名）密码请求服务器
• 服务器验证用户账号是否和数据库匹配
• 服务器通过验证后发送给客户端一个 JWT Token
• 客户端存储 Token，并在每次请求时携带该 Token（如何携带?）
• 服务端验证 Token 值，并根据 Token 合法性返回对应资源（如何验证?）

安全限制

为防止用户恶意注册，系统对 IP 默认进行了限制，条件如下：

• 单 IP 5 分钟内连续注册超过 3 次会被禁止；
• 单 IP 5 分钟内连续登录失败超过 3 次会要求输入验证码；

你可以自定义时间范围和该时间段内次数的阈值。

若想开启/关闭或修改此限制，请参考：开启/关闭/配置注册频率限制。

客户端附带 JWT Token 的方式

用户在完成认证后会返回开发者一个 JWT Token，开发者需将此 Token 存储于客户端，然后将此 Token 发送给开发者受限的后端服务器进行验证。

建议使用 HTTP Header Authorization 的形式携带 Token，以下以 JavaScript 的 axios 库为例示范如何携带：

const axios = require("axios"); axios .get({ url: "https://yourdomain.com/api/v1/your/resources" headers: { Authorization: "Bearer ID_TOKEN" } }) .then((res) => { // custom codes });

注意第五行前面有 Bearer 类型。

Bearer 是什么意思?

Bearer Token (RFC 6750 (opens new window)) 用于授权访问资源，任何 Bearer 持有者都可以无差别地用它来访问相关的资源，而无需证明持有加密 key。一个 Bearer 代表授权范围、有效期，以及其他授权事项；一个 Bearer 在存储和传输过程中应当防止泄露，需实现 Transport Layer Security (TLS)；一个 Bearer 有效期不能过长，过期后可用 Refresh Token 申请更新。

建议开发者遵循规范，在每次请求的 Token 前附带 Bearer。

在 Authing 中，无需手动编写操作 session、cookie 或是 token，控制台中可以一键体验单点登录功能，并且支持自建与集成第三方等多种方式，还可以通过 SDK 接入并自定义自己的应用与登录方式。

如果你喜欢我们的内容，欢迎关注公众号「Authing 身份云」或者点击「链接」，体验 Authing。