安基网 首页 安全 安全学院 查看内容

单点登录技术中的 Token 认证是什么?

2020-9-8 10:01| 投稿: |来自:


免责声明:本站系公益性非盈利IT技术普及网,本文由投稿者转载自互联网的公开文章,文末均已注明出处,其内容和图片版权归原网站或作者所有,文中所述不代表本站观点,若有无意侵权或转载不当之处请从网站右下角联系我们处理,谢谢合作!

摘要: 单点登录在技术上涉及协议对接、认证方式等诸多细节,我们这里先来聊聊认证方式。由于传统基于 Session 认证方式的局限性,目前单点登录技术中一般使用 Token 认证,它具有扩展性好、服务端负载轻、支持移动端访问、不需要CSRF防护等优势。下文将详细介绍 Token 认证的技术细节。一、传统基于 Session ...

单点登录在技术上涉及协议对接、认证方式等诸多细节,我们这里先来聊聊认证方式。由于传统基于 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 认证有效解决了客户端多次输入用户名和密码的问题,但存在诸多弊端:

  • 服务端成本上升:每个用户在客户端进行登录操作后,服务端都需要进行一次 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进 行验签和确认,从而有效确保用户私密信息不会被盗。举个例子,玉符 IDaaS 在单点登录上采用 JWT 进行身份认证的 Token 签发和验签,整个过程中没有密码等私密信息的传递,只会在跨服务器的信息共享中传输像邮箱这样的身份标识符号,这样可以从根本上规避身份认证信息泄露引发的数据泄露问题。当然软件工程的世界里没有“银弹”,我们在玉符IDaaS设计中采用了多种机制为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 信息的安全。

解释一下 IDaaS:

IDaaS 即提供基于云的身份认证和管理服务的平台,确保在准确判定用户身份的基础上,在正确的时间授予用户正确的应用、文件和其他资源的访问权限。IDaaS 能提供多种标准化功能帮助用户实现高效、安全的身份认证管理服务,如单点登录、智能多因素认证、账号生命周期管理等等。
由于 IDaaS 在国内尚属于新兴产品形态,很多人对它只有模糊的印象,所以我们计划用一系列文章,深入浅出介绍 IDaaS 相关的技术原理和细节。


本文是“IDaaS 技术解析”系列的第一篇。后续我们将继续带来更多 IDaaS 身份认证管理领域的技术解读,欢迎关注我们的专栏,或留下你的想法与我们交流~



小编推荐:欲学习电脑技术、系统维护、网络管理、编程开发和安全攻防等高端IT技术,请 点击这里 注册账号,公开课频道价值万元IT培训教程免费学,让您少走弯路、事半功倍,好工作升职加薪!

本文出自:https://www.toutiao.com/i6868146830304084484/

免责声明:本站系公益性非盈利IT技术普及网,本文由投稿者转载自互联网的公开文章,文末均已注明出处,其内容和图片版权归原网站或作者所有,文中所述不代表本站观点,若有无意侵权或转载不当之处请从网站右下角联系我们处理,谢谢合作!

相关阅读

最新评论

 最新
返回顶部
极速赛车两期公式 湖北快3走势 极速3D彩票 乐彩网 山东11选5开奖 爱投彩票计划群 海南4+1走势图 上海11选5开奖 拉菲彩票计划群 极速赛车怎么玩最保险