IDaaS 即提供基于云的身份认证和管理服务的平台，确保在准确判定用户身份的基础上，在正确的时间授予用户正确的应用、文件和其他资源的访问权限。IDaaS 能提供多种标准化功能帮助用户实现高效、安全的身份认证管理服务，如单点登录、智能多因素认证、账号生命周期管理等等。

 

由于 IDaaS 在国内尚属于新兴产品形态，很多人对它只有模糊的印象，所以我们计划用一系列文章，深入浅出介绍 IDaaS 相关的技术原理和细节。本文是“IDaaS 技术解析”系列的第一篇。

 

 

单点登录是 IDaaS 平台提供的关键功能之一，技术上涉及协议对接、认证方式等诸多细节，我们今天先来聊聊认证方式。由于传统基于 Session 认证方式的局限性，目前单点登录技术中一般使用 Token 认证，下文将详细介绍 Token 认证的流程及相对优势。

 

一、传统基于 Session 的认证方式

 

在介绍 Token 认证前，先简单介绍一下传统基于 Session 的认证。早前由于 Http 协议无状态的特性（每次客户端和服务端会话完成时，服务端不会保存会话信息，包括用户上一次登录时输入的用户名和密码），于是基于 Session的有状态的认证方式逐渐成为一种流行技术方案，以减少用户在登录客户端时输入用户名和密码的认证操作次数。

 

简单来说，基于 Session 的认证就是让客户端和服务端之间的认证会话以Session的形式进行存储，并通过在服务端和客户端之间传输 Session，来实现两方之间的身份认证交流。具体流程如下：

 

1. 用户在客户端输入用户名和密码，进行登录操作；

2. 服务端用户身份验证通过，生成 Session，并存入数据库中；

3. 客户端在浏览器上生成 Cookie，并把 Session 写入其中；

4. 用户在客户端后续有新的请求，都会在请求时携带 Session，并发给服务端；

5. 如果客户端 log out，之前生成的 Session 会在客户端和服务端都会被销毁。

 

虽然 Session 认证有效解决了客户端多次输入用户名和密码的问题，但存在诸多弊端：

 

· 服务端成本上升：每个用户在客户端进行登录操作后，服务端都需要进行一次 Session 记录，随着注册用户不断增多，存储 Session 就会占用大服务器内存，大型应用可能还需要借助数据库或者一系列缓存机制存储 Session。

 

· 无法横向扩展: Session 认证方式在跨服务或跨域的资源共享方面表现很差。比如，多个子域名提供同一个应用服务，或者单点登录中用户通过一套用户名和密码同时登录多个应用系统，Session 认证方式在这样的场景中就无法再起作用，尤其是对于分布式应用而言，这种认证方式很难在多个服务器负载上进行横向拓展。

 

· CSRF跨站点请求伪造(Cross—Site Request Forgery): Cookies 存在很多不安全因素，如果 Cookies 被截获，用户就会很容易受到 CSRF 的攻击，导致数据泄露。

 

二、基于 Token 的认证方式

 

Token 认证是无状态的，其核心是签名和验签。客户端每次向服务端发送请求时都会携带 Token，这里的 Token 是服务端用自己的密钥签名的，当服务端接收到 Token 时会用自己的密钥去验签，判断这个 Token 是否是自己签发的，进而对用户身份进行验证。具体流程如下：

 

 

1. 客户端使用用户名和密码请求登录；

2. 服务端收到请求，去验证用户名与密码；

3. 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端（一般用哈希算法再加个随机数）；

4. 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里；

5. 客户端每次向服务端请求资源的时候需要携带服务端签发的 Token；

6. 服务端收到请求，然后去验证客户端请求里面携带的Token，如果验证成功，就向客户端返回请求的数据。

 

从以上流程中可以看到，相较于传统的 Session 认证，Token 认证在成本、可扩展性和安全性等方面都有一定的优势：

 

· 服务端负载减轻：服务端无需对生成的Token进行保存，只需要对Token进行签发和验签即可。Token中写入很多身份验证中所需要的信息，比如哈希签名算法、用户信息和签名，服务端的负载会减轻许多。

 

· 通过API实现横向扩展：基于Token的认证通过API调用的方式，可以将Token认证应用到不同的服务和域中，使分布式应用的身份认证实现起来更高效便捷。

 

· 不需要CSRF防护：由于不需要依赖Cookie，自然不用担心Cookie被截获，以及由此引发的用户信息被伪造登录的问题。

 

· 支持移动端访问：Cookie本身不支持手机端访问，Token认证机制在移动端具有极大的优势。

 

JSON Web Token（JWT）是目前在单点登录实践中最为通用的Token认证方式。JWT包含头部（header）、载荷（payload）和签名（signature）三部分。IDP（Identity Provider,即身份服务提供者）会将用户数据以加密的形式写入JWT，SP（Service Provider，服务提供者）会对 JWT 进行存储，IDP 会在随后的 SP 每次请求中对 JWT进 行验签和确认，从而有效确保用户私密信息不会被盗。

 

举个例子，在单点登录上采用 JWT 进行身份认证的 Token 签发和验签，整个过程中没有密码等私密信息的传递，只会在跨服务器的信息共享中传输像邮箱这样的身份标识符号，这样可以从根本上规避身份认证信息泄露引发的数据泄露问题。

 

也可采用其他多种机制为Token的安全加码：

 

  • 采用 HTTPS 的形式对 Token 进行加密，对于常见的浏览器和操作系统，强制使用 TLS1.2 协议，而禁用 SSLv3（SSL MODE SEND FALLBACK SCSV）。服务所用 HTTPS 证书来自知名证书机构 GeoTrust，具有极高可用性，最高 256 位 SSL 加密，杜绝中间人监听；
  • 在 JWT 和对接应用服务之间采用定期密钥轮转机制，所有颁发的 Token 都具备强时效性，防止 Token 的超前使用或者过期使用，同时支持一次性 Token，使用过的 Token 也可以被记录并禁止二次使用，从而降低偷窃者破解使用 Token 的可能性；
  • 对于 Cookie 的安全，玉符全域防止 Cookie 挟持（Hijacking）和重放攻击（Replay Attacks），并且所有超过 5 分钟有效期的 Cookie 都可以在受威胁情况下强制失效，有效确保存储在 Cookie 中 Token 信息的安全。