单点登录在技术上涉及协议对接、认证方式等诸多细节,我们这里先来聊聊认证方式。由于传统基于 Session 认证方式的局限性,目前单点登录技术中一般使用 Token 认证,它具有扩展性好、服务端负载轻、支持移动端访问、不需要CSRF防护等优势。下文将详细介绍 Token 认证的技术细节。 一、传统基于 Session 的认证方式在介绍 Token 认证前,先简单介绍一下传统基于 Session 的认证。早前由于 Http 协议无状态的特性(每次客户端和服务端会话完成时,服务端不会保存会话信息,包括用户上一次登录时输入的用户名和密码),于是基于 Session的有状态的认证方式逐渐成为一种流行技术方案,以减少用户在登录客户端时输入用户名和密码的认证操作次数。 简单来说,基于 Session 的认证就是让客户端和服务端之间的认证会话以Session的形式进行存储,并通过在服务端和客户端之间传输 Session,来实现两方之间的身份认证交流。具体流程如下: 1. 用户在客户端输入用户名和密码,进行登录操作; 2. 服务端用户身份验证通过,生成 Session,并存入数据库中; 3. 客户端在浏览器上生成 Cookie,并把 Session 写入其中; 4. 用户在客户端后续有新的请求,都会在请求时携带 Session,并发给服务端; 5. 如果客户端 log out,之前生成的 Session 会在客户端和服务端都会被销毁。 虽然 Session 认证有效解决了客户端多次输入用户名和密码的问题,但存在诸多弊端:
二、基于 Token 的认证方式Token 认证是无状态的,其核心是签名和验签。客户端每次向服务端发送请求时都会携带 Token,这里的 Token 是服务端用自己的密钥签名的,当服务端接收到 Token 时会用自己的密钥去验签,判断这个 Token 是否是自己签发的,进而对用户身份进行验证。具体流程如下: 1. 客户端使用用户名和密码请求登录; 2. 服务端收到请求,去验证用户名与密码; 3. 验证成功后,服务端会签发一个 Token,再把这个 Token 发送给客户端(一般用哈希算法再加个随机数); 4. 客户端收到 Token 以后可以把它存储起来,比如放在 Cookie 里或者 Local Storage 里; 5. 客户端每次向服务端请求资源的时候需要携带服务端签发的 Token; 6. 服务端收到请求,然后去验证客户端请求里面携带的Token,如果验证成功,就向客户端返回请求的数据。 从以上流程中可以看到,相较于传统的 Session 认证,Token 认证在成本、可扩展性和安全性等方面都有一定的优势:
JSON Web Token(JWT)是目前在单点登录实践中最为通用的Token认证方式。JWT包含头部(header)、载荷(payload)和签名(signature)三部分。IDP(Identity Provider,即身份服务提供者)会将用户数据以加密的形式写入JWT,SP(Service Provider,服务提供者)会对 JWT 进行存储,IDP 会在随后的 SP 每次请求中对 JWT进 行验签和确认,从而有效确保用户私密信息不会被盗。 举个例子,玉符 IDaaS 在单点登录上采用 JWT 进行身份认证的 Token 签发和验签,整个过程中没有密码等私密信息的传递,只会在跨服务器的信息共享中传输像邮箱这样的身份标识符号,这样可以从根本上规避身份认证信息泄露引发的数据泄露问题。 当然软件工程的世界里没有“银弹”,我们在玉符IDaaS设计中采用了多种机制为Token的安全加码——
|
|