Token 认证

From今日头条:https://www.toutiao.com/i6516654967204348430/?tt_from=weixin&utm_campaign=client_share&from=singlemessage&timestamp=1519736895&app=news_article&utm_source=weixin&iid=24063074966&utm_medium=toutiao_android&wxshare_count=1

Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证,服务端认证成功,那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位。

一、为什么要用 Token?

Token可以解决如下问题:

1、Token 完全由应用管理,所以它可以避开同源策略

2、Token 可以避免 CSRF 攻击

3、Token 可以是无状态的,可以在多个服务间共享

Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证,服务端认证成功,那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位。如果这个 Token 在服务端持久化(比如存入数据库),那它就是一个永久的身份令牌

二、需要为Token设置有效期嘛?

针对该问题,看如下二个例子:

1、登录密码,一般要求定期改变密码,以防止泄漏,所以密码是有有效期的

2、安全证书,SSL 安全证书都有有效期,目的是为了解决吊销的问题

因此无论是从安全的角度考虑,还是从吊销的角度考虑,Token 都需要设有效期

三、Tocken有效期设置多长时间合适?

根据系统的安全需要,尽可能的短,但也不能短得离谱——想像一下手机的自动熄屏时间,如果设置为 10 秒钟无操作自动熄屏,再次点亮需要输入密码,会不会疯?

如果用户在正常操作的过程中,Token 过期失效了,要求用户重新登录……用户体验岂不很糟糕?

为了解决在操作过程不能让用户感到 Token 失效这个问题,有2种方案:

1、在服务器端保存 Token 状态,用户每次操作都会自动刷新(推迟) Token 的过期时间

     ----Session 就是采用这种策略来保持用户登录状态的

     然而仍然存在这样一个问题,在前后端分离、单页 App 这些情况下,每秒种可能发起很多次请求,每次都去刷新过期时间会产生非常大的代价。如果 Token 的过期时间被持久化到数据库或文件,代价就更大了。所以通常为了提升效率,减少消耗,会把 Token 的过期时间保存在缓存或者内存中

2、使用 Refresh Token  --它可以避免频繁的读写操作

服务端不需要刷新 Token 的过期时间,一旦 Token 过期,就反馈给前端,前端使用 Refresh Token 申请一个全新 Token 继续使用。这种方案中,服务端只需要在客户端请求更新 Token 的时候对 Refresh Token 的有效性进行一次检查,大大减少了更新有效期的操作,也就避免了频繁读写。当然 Refresh Token 也是有有效期的,但是这个有效期就可以长一点了,比如,以天为单位的时间。

四、使用 Token 和 Refresh Token 的时序图表示---有状态Token(即在服务端需要保存并记录相关属性)

1、登录

2、业务请求

3、Token过期,刷新Token

注意:上面的时序图中并未提到 Refresh Token 过期怎么办。不过很显然,Refresh Token 既然已经过期,就该要求用户重新登录了。

当然还可以把这个机制设计得更复杂一些,如:Refresh Token 每次使用的时候,都更新它的过期时间,直到与它的创建时间相比,已经超过了非常长的一段时间(如三个月),这等于是在相当长一段时间内允许 Refresh Token 自动续期。

五、无状态Token

1、应用无状态Token注意2点:

【1】Refresh Token 有效时间较长,所以它应该在服务器端有状态,以增强安全性,确保用户注销时可控

【2】应该考虑使用二次认证来增强敏感操作的安全性

(一)认证服务和业务服务集成情况

如果我们把所有状态信息都附加在 Token 上,服务器就可以不保存。但是服务端仍然需要认证 Token 有效。不过只要服务端能确认是自己签发的 Token,而且其信息未被改动过,那就可以认为 Token 有效——“签名”可以作此保证。平时常说的签名都存在一方签发,另一方验证的情况,所以要使用非对称加密算法。但是在这里,签发和验证都是同一方,所以对称加密算法就能达到要求,而对称算法比非对称算法要快得多(可达数十倍差距)。更进一步思考,对称加密算法除了加密,还带有还原加密内容的功能,而这一功能在对 Token 签名时并无必要——既然不需要解密,摘要(散列)算法就会更快。可以指定密码的散列算法,自然是 HMAC

上述不需要自己去实现,JWT 已经定义了详细的规范,而且有各种语言的若干实现

不过在使用无状态 Token 的时候在服务端会有一些变化,服务端虽然不保存有效的 Token 了,却需要保存未到期却已注销的 Token。如果一个 Token 未到期就被用户主动注销,那么服务器需要保存这个被注销的 Token,以便下次收到使用这个仍在有效期内的 Token 时判其无效。有没有感到一点沮丧?

在前端可控的情况下(比如前端和服务端在同一个项目组内),可以协商:前端一但注销成功,就丢掉本地保存(比如保存在内存、LocalStorage 等)的 Token 和 Refresh Token。基于这样的约定,服务器就可以假设收到的 Token 一定是没注销的(因为注销之后前端就不会再使用了)。

如果前端不可控的情况,仍然可以进行上面的假设,但是这种情况下,需要尽量缩短 Token 的有效期,而且必须在用户主动注销的情况下让 Refresh Token 无效。这个操作存在一定的安全漏洞,因为用户会认为已经注销了,实际上在较短的一段时间内并没有注销。如果应用设计中,这点漏洞并不会造成什么损失,那采用这种策略就是可行的。

(二)认证服务和业务服务分离情况

Token 无状态之后,单点登录就变得容易了。前端拿到一个有效的 Token,它就可以在任何同一体系的服务上认证通过——只要它们使用同样的密钥和算法认证 Token 的有效性。(单点登录:一处登录,处处登录)

当然,如果 Token 过期了,前端仍然需要去认证服务更新 Token

可见,虽然认证和业务分离了,实际即并没产生多大的差异。当然,这是建立在认证服务器信任业务服务器的前提下,因为认证服务器产生 Token 的密钥和业务服务器认证 Token 的密钥和算法相同。换句话说,业务服务器同样可以创建有效的 Token

注:如果业务服务器不能被信任,该怎么办? ---不受信的业务服务器

遇到不受信的业务服务器时,很容易想到的办法是使用不同的密钥。认证服务器使用密钥1签发,业务服务器使用密钥2验证——这是典型非对称加密签名的应用场景。认证服务器自己使用私钥对 Token 签名,公开公钥信任这个认证服务器的业务服务器保存公钥,用于验证签名。幸好,JWT 不仅可以使用 HMAC 签名,也可以使用 RSA(一种非对称加密算法)签名。

不过,当业务服务器已经不受信任的时候,多个业务服务器之间使用相同的 Token 对用户来说是不安全的。因为任何一个服务器拿到 Token 都可以仿冒用户去另一个服务器处理业务。。。

为了防止这种情况发生,就需要在认证服务器产生 Token 的时候,把使用该 Token 的业务服务器的信息记录在 Token 中,这样当另一个业务服务器拿到这个 Token 的时候,发现它并不是自己应该验证的 Token,就可以直接拒绝。

现在,认证服务器不信任业务服务器,业务服务器相互也不信任,但前端是信任这些服务器的——如果前端不信任,就不会拿 Token 去请求验证。那么为什么会信任?可能是因为这些是同一家公司或者同一个项目中提供的若干服务构成的服务体系。

但是,前端信任不代表用户信任。如果 Token 没有携带用户隐私(比如姓名),那么用户不会关心信任问题。但如果 Token 含有用户隐私的时候,用户得关心信任问题了。这时候认证服务就不得不再啰嗦一些,当用户请求 Token 的时候,问上一句,你真的要授权给某某某业务服务吗?而这个“某某某”,用户怎么知道它是不是真的“某某某”呢?用户当然不知道,甚至认证服务也不知道,因为公钥已经公开了,任何一个业务都可以声明自己是“某某某”。

为了得到用户的信任,认证服务就不得不帮助用户来甄别业务服务。所以,认证服器决定不公开公钥,而是要求业务服务先申请注册并通过审核只有通过审核的业务服务器才能得到认证服务为它创建的,仅供它使用的公钥。如果该业务服务泄漏公钥带来风险,由该业务服务自行承担。现在认证服务可以清楚的告诉用户,“某某某”服务是什么了。如果用户还是不够信任,认证服务甚至可以问,某某某业务服务需要请求 A、B、C 三项个人数据,其中 A 是必须的,不然它不工作,是否允许授权?如果你授权,我就把你授权的几项数据加密放在 Token 中……

这类似开放式 API 的认证过程。开发式 API 多采用 OAuth 认证

Token 认证的更多相关文章

  1. 基于Token认证的多点登录和WebApi保护

    在文章中有错误的地方,或是有建议或意见的地方,请大家多多指正,邮箱: linjie.rd@gmail.com 一天张三,李四,王五,赵六去动物园,张三没买票,李四制作了个假票,王五买了票,赵六要直接F ...

  2. 【翻译】asp.net core2.0中的token认证

    原文地址:https://developer.okta.com/blog/2018/03/23/token-authentication-aspnetcore-complete-guide token ...

  3. Java实现基于token认证

    随着互联网的不断发展,技术的迭代也非常之快.我们的用户认证也从刚开始的用户名密码转变到基于cookie的session认证,然而到了今天,这种认证已经不能满足与我们的业务需求了(分布式,微服务).我们 ...

  4. flask token认证

    在前后端分离的项目中,我们现在多半会使用token认证机制实现登录权限验证. token通常会给一个过期时间,这样即使token泄露了,危害期也只是在有效时间内,超过这个有效时间,token过期了,就 ...

  5. laravel5.7 前后端分离开发 实现基于API请求的token认证

    最近在学习前后端分离开发,发现 在laravel中实现前后台分离是无法无法使用 CSRF Token 认证的.因为 web 请求的用户认证是通过Session和客户端Cookie的实现的,而前后端分离 ...

  6. python 全栈开发,Day97(Token 认证的来龙去脉,DRF认证,DRF权限,DRF节流)

    昨日内容回顾 1. 五个葫芦娃和三行代码 APIView(views.View) 1. 封装了Django的request - request.query_params --> 取URL中的参数 ...

  7. django使用RestFramework的Token认证

    今天实现的想法有点不正规: Django Rest framework的框架的认证,API都运行良好. 现在是要自己写一个function来实现用户的功能. 而不是用Rest 框架里的APIVIEW这 ...

  8. 基于nginx的token认证

    Nginx 的 token 认证是基于集成了 nginx+lua 的 openresty 来实现的. 环境: centos 7 部署方式: 增量部署(不影响原 nginx 版本) 版本: openre ...

  9. Token认证登录以及权限控制

    IdentityServer4实现Token认证登录以及权限控制   相关知识点 不再对IdentityServer4做相关介绍,博客园上已经有人出了相关的系列文章,不了解的可以看一下: 蟋蟀大神的: ...

  10. Flask扩展实现HTTP令牌token认证HTTPTokenAuth

    Token认证 在restful设计中,用户认证模式通常使用json web token,而不会使用传统的HTTP Basic认证(传入账号密码) token认证模式如下:在请求header中加入to ...

随机推荐

  1. mkswap - 建立一个linux交换区

    总览 mkswap [-c] [-vN] [-f] device [size] 描述 mkswap 在一个设备上或者在一个文件里创建一个linux交换区. (该交换区创建后,必须使用 swapon 命 ...

  2. elasticsearch——Rest Client

    https://www.jianshu.com/p/66b91bec12e3 elasticsearch——Rest Client 0.2372018.05.10 15:23:03字数 1287阅读 ...

  3. Testbench学习笔记

    Testbench学习笔记(一) 书写testbench是数字电路设计中不可或缺的一项设计方法,主要是提供的是激励.尽管现在各种开发工具都通过绘制波形图的方法生成测试激励,测试书写的代码,但是其不可移 ...

  4. Numpy使用方法

    地址:http://www.cnblogs.com/xinchrome/p/5043480.html 另附Stanford的Numpy Tutorial地址:http://cs231n.github. ...

  5. AC电源品字插座和空开接线图

  6. java多线程sleep,wait,yield方法区别

    sleep() 方法sleep()的作用是在指定的毫秒数内让当前“正在执行的线程”休眠(暂停执行).这个“正在执行的线程”是指this.currentThread()返回的线程.sleep方法有两个重 ...

  7. Extjs中如何在一行textfield后面增加文字提示

    添加监听事件: listeners: {               render: function(obj) {                     var font=document.cre ...

  8. Arduino-一些函数

    随机函数: int x=random();  //返回一个整型随机数 int x=random(10);  //返回一个 [0,10) 整型随机数 int x=random(1,8);  //返回一个 ...

  9. 在浏览器下载pdf,或者txt文档是会直接打开

    window.location.href = url会直接打开,解释大概是因为浏览器自身可以解析.pdf或者txt.解决方法如下: 本来就要用a标签里面加上download属性的,结果发现不行,就算了 ...

  10. 面试题常考&必考之--http访问一个页面的全流程(Tcp/IP协议)

    分析:-http访问一个页面的全流程,也就好比我们在地址栏输入地址,然后点击回车进行访问 该面试题的主要考点是:计算机网络的TCP/IP协议栈 描述图片:首先应用层提交http请求,传到传输层后由,T ...