大家好，关于深入学习Token认证知识很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！
而这个问题的答案很简单——，因为它解决了问题！可以解决哪些问题？
令牌完全由应用程序管理，因此可以避免同源策略。 Token可以避免CSRF攻击（http://dwz.cn/7joLzx）。令牌可以是无状态的并在多个服务之间共享。 Token是在服务器端生成的。如果前端使用用户名/密码向服务器请求认证，服务器认证成功，服务器会返回一个Token给前端。前端每次请求都可以带上Token来证明自己的合法地位。如果这个Token被持久化在服务器端（比如存储在数据库中），那么它就是一个永久的身份令牌。
那么，又一个问题出现了：Token需要设置有效期吗？
2. 需要设置有效期吗？
对于这个问题，我们不妨先看两个例子。一个例子就是登录密码，一般需要定期更改，防止泄露，因此密码是有有效期的；另一个例子是安全证书。 SSL安全证书有一个有效期，以解决吊销问题。关于这个问题的详细内容可以看看知乎的回答（http://dwz.cn/7joMhq）。因此，无论从安全还是撤销的角度来看，Token都需要有一个有效期。
那么有效期是多少合适呢？
只能说，根据系统的安全需求，应该越短越好，但也不能短得离谱。 —— 想象一下手机自动熄屏的时间。如果设置为10秒无操作自动关闭屏幕，则需要输入密码才能再次打开屏幕。你会发疯吗？如果你觉得不行，那就自己试试，把时间设置成能设置的最短时间。坚持一周就可以了（不排除这个时间有人能适应，毕竟手机厂商也是进行用户体验研究的）。
那么新的问题就出现了。如果正常操作时用户的token过期了，需要用户重新登录……那用户体验不是很糟糕吗？
为了解决操作过程中不让用户感觉Token无效的问题，一种解决方案是在服务器端保存Token状态。用户每次操作时，Token过期时间都会自动刷新（推迟）。 ——Session使用该策略来维护用户登录状态。的。然而，仍然存在一个问题。在前端和单页应用分离的情况下，每秒可能会发起很多请求，每次刷新过期时间都会产生非常高的成本。如果将Token过期时间持久化到数据库或者文件中，成本会更大。因此，为了提高效率、减少消耗，Token在过期时通常会存储在缓存或内存中。
还有一种解决方案，使用Refresh Token，可以避免频繁的读写操作。在该方案中，服务器不需要刷新Token的过期时间。一旦Token过期，就会反馈给前端，前端通过Refresh Token申请新的Token继续使用。该方案中，当客户端请求更新Token时，服务端只需要检查一次Refresh Token的有效性，大大减少了更新有效期的操作，避免了频繁的读写。当然，Refresh Token也是有有效期的，但是这个有效期可以更长，比如以天为单位。
3. 时序图表示
使用Token和Refresh Token的时序图如下：
1）登录
2）业务请求
3）Token过期，刷新Token
上面的序列图没有提到如果刷新令牌过期了该怎么办。但显然，由于Refresh Token 已经过期，是时候要求用户重新登录了。当然，这个机制可以设计得更复杂。每次使用刷新令牌时，其过期时间都会更新，直到超过其创建时间很长一段时间（例如三个月）。相当于让Refresh Token可以自动续订很长一段时间。目前为止，Token都是有状态的，即相关属性需要在服务器端保存记录。那么无国籍呢，如何实现呢？
4. 无状态代币
如果我们将所有状态信息附加到Token上，那么服务器就不需要保存它。但服务器仍然需要验证令牌是否有效。但是，只要服务器能够确认该Token是自己颁发的，并且其信息没有被修改，就可以认为该Token是有效的。 ——“签名”可以提供这种保证。常见的签名都是由一方签名，另一方验证，因此必须使用非对称加密算法。但这里，签名方和验证方都是同一个人，所以对称加密算法就可以满足要求，而且对称算法比非对称算法快很多（最多相差几十倍）。
进一步思考，对称加密算法除了加密之外，还具有恢复加密内容的功能，而在对Token进行签名时，这个功能并不是必须的。 —— 由于不需要解密，摘要（哈希）算法会更快。你可以指定密码哈希算法，自然是HMAC。
上面说了这么多，还需要自己实现吗？不必！ JWT 定义了详细的规范，并且有多种语言的实现。
然而，当使用无状态令牌时，服务器端会发生一些变化。虽然服务器不保存有效的令牌，但需要保存未过期但已取消的令牌。如果某个Token在过期前被用户主动取消，那么服务器需要保存取消的Token，以便下次收到仍然有效的Token时失效。有没有感到有点沮丧？
当前端可控时（例如前端和服务端在同一个项目组），可以协商：一旦前端注销成功，就会丢失本地保存的Token和Refresh Token （如存储在内存、LocalStorage等）。基于这个协议，服务器可以假设收到的Token一定是没有注销的（因为注销后前端就不再使用它了）。
如果前端不可控的话，上述假设仍然可以成立，但这种情况下，需要尽可能缩短Token的有效期，并且当用户主动注销时，Refresh Token必须失效。这种操作存在一定的安全漏洞，因为用户会认为自己已经注销了，但实际上短时间内并没有注销。如果这个漏洞不会对应用程序设计造成任何损失，那么这个策略是可行的。
使用无状态代币时，有两点需要注意：
Refresh Token是长期有效的，所以在服务器端应该是有状态的，以增强安全性，保证用户注销时的可控性。您应该考虑使用两步身份验证来增强敏感操作的安全性。至此，关于Token的话题似乎就差不多结束了。 —— 然而，事实并非如此。上面提到的只是认证服务和业务服务集成在一起的情况。如果他们分开了怎么办？
5. 单独的认证服务
当Token无状态时，单点登录变得容易。一旦前端获得了有效的Token，就可以在同一系统——的任何服务上进行验证，只要它们使用相同的密钥和算法来验证Token的有效性。就像这样：
当然，如果Token过期了，前端还是需要去认证服务更新Token：
可见，认证与业务虽然分离，但实践中并没有太大区别。当然，这是建立在认证服务器信任业务服务器的前提下的，因为认证服务器生成Token所使用的密钥与业务服务器认证Token所使用的密钥和算法是相同的。也就是说，业务服务器也可以创建有效的Token。
如果业务服务器不可信怎么办？
6. 不可信的业务服务器
当遇到不受信任的业务服务器时，很容易想到使用不同的密钥。认证服务器使用密钥1颁发，业务服务器使用密钥2验证——，这是非对称加密签名的典型应用场景。认证服务器使用自己的私钥对Token进行签名，并将公钥公开。信任该认证服务器的业务服务器保存公钥，用于验证签名。幸运的是，JWT 不仅可以使用HMAC 进行签名，还可以使用RSA（一种非对称加密算法）进行签名。
但是，当业务服务器不再可信时，用户在多个业务服务器之间使用同一个Token是不安全的。因为任何拿到Token的服务器都可以冒充用户，去另一台服务器处理业务……悲剧随时可能发生。
为了防止这种情况发生，在认证服务器生成Token时，需要在Token中记录使用该Token的业务服务器的信息，这样当其他业务服务器获取到该Token时，发现不是它应该是什么。验证过的Token可以直接拒绝。
现在，认证服务器不信任业务服务器，业务服务器之间也互不信任，但是前端信任这些服务器。 —— 如果前端不信任，则不会使用Token来请求验证。那么为什么要信任呢？可能是因为这些是由同一家公司或同一项目提供的多项服务组成的服务系统。
原创文章，作者：小su，如若转载，请注明出处：https://www.sudun.com/ask/158453.html
用户评论
轨迹！
这篇文章简直太棒了！我之前对 Token 认证了解很少，看完之后感觉豁然开朗，终于知道以前那些安全问题是怎么发生的。作者解释得很清楚，配图也很生动，让我更容易理解这些概念。
有11位网友表示赞同！
赋流云
我一直觉得网络安全的知识都很难懂，但这篇文章却很不一样，用通俗易懂的语言讲解复杂的 Token 认证机制，简直就是良心博文！我强烈推荐给所有想了解网络安全的朋友们阅读。
有12位网友表示赞同！
有你，很幸福
Token 认证确实是一个比较重要的概念，但在实际开发过程中，我还是会遇到一些问题。比如，如何更有效地管理和存储 Token？这篇文章虽然介绍了基本的知识，但对于实战应用的细节还是不够深入。希望作者后续可以分享一些实际案例和经验。
有18位网友表示赞同！
爱情的过失
我觉得这篇文章把 Token 认证讲得有点太水了，缺乏真实案例和实践经验分享，主要还是停留在理论层面。如果能加入一些具体的技术实现和常见问题解决方法，会更实用和有价值。
有6位网友表示赞同！
自繩自縛
Token 认证的确是一个比较新的概念，需要我们不断学习和实践。这篇文章虽然没有深入探讨某个特定场景，但它为初学者提供了一个很好的入门指南，帮助我们了解 Token 的工作原理和应用范围。感谢作者的分享！
有6位网友表示赞同！
一尾流莺
作为一名系统管理员，我对 Token 认证非常感兴趣，因为我们需要保证用户的身份验证和资源访问的安全。这篇文章讲解了 Token 的基本概念，也介绍了一些常用的安全实践，对我的工作思路很有帮助。
有15位网友表示赞同！
心贝
这篇博文把 Token 认证的原理解释得很清晰，让我一下子就明白了它的作用机制。以前我一直觉得网络安全很复杂，但现在看来只要掌握一些基本的知识就可以理解很多问题了！
有11位网友表示赞同！
醉婉笙歌
这篇文章主要讲 Token 认证的基本概念，对于想入门的人来说比较合适，但对我这种已经学习过 JWT 和 OAuth 的老用户来说有点浅显。希望作者后续能分享更深入的讨论和实战经验。
有9位网友表示赞同！
裸睡の鱼
其实我平时很少接触 Token 认证这个概念，但看完这篇文章后感觉它在很多场景下都可以发挥作用，比如电商平台的用户登录、API 接口的安全验证等。现在看来学习一下 Token 认证确实很有必要！
有15位网友表示赞同！
青袂婉约
我觉得这篇文章把 Token 认证讲得很简单，缺乏对不同类型 Token 的详细介绍和比较分析。例如 OAuth2 和 OpenID Connect 都使用了 Token 认证机制，但它们在应用场景和功能上还是有很多区别的。
有17位网友表示赞同！
此生一诺
作为一名软件开发工程师，我对网络安全一直很重视。这篇文章讲解了 Token 认证原理以及一些常见的攻击手段，让我更加了解如何保护自己的系统和数据安全。感谢作者的分享！
有11位网友表示赞同！
tina
这篇文章把 Token 认证的概念解释得非常清楚，而且还附带了一些代码示例，非常实用！作为一名初级程序员，学习起来更容易理解，谢谢作者的不懈努力。
有14位网友表示赞同！
落花忆梦
我覺得這篇文章對於想要了解Token認證的人來說是一個很好的入門指南。它解釋了Token的工作原理以及一些常見的應用場景，讓我對這個概念有了一個更清晰的認識。感謝作者的分享！
有9位网友表示赞同！
一生荒唐
我对 Token 认证的理解还比较浅薄，这篇文章让我对它的工作原理有了更深入的了解。特别是它提到的一些安全注意事项，令我受益匪浅，以后开发的时候一定要更加谨慎。
有11位网友表示赞同！
长裙绿衣
Token 认证是一个非常实用的技术，但在实际应用中需要注意各种安全问题。这篇文章虽然没有介绍具体的实施细节，但它强调了这些安全注意事项，提醒了我们要谨慎对待 Token 的使用和维护, 这对我很有启发！
有5位网友表示赞同！
逃避
这个话题确实很关键！这篇文章让我更深刻地认识到，Token 认证的重要性不仅仅限于网络安全，甚至在日常生活中的很多领域都可以应用。希望作者能继续挖掘其更广泛的应用场景，分享更多实用经验。
有20位网友表示赞同！