摘要：最近读了几篇大牛的博客才对认证机制方面有了进一步了解。尽管在服务器端可以优雅地使用技术如拦截器或动态代理对所有进行前置的登录验证。认证方式比较支持问题和其实是紧密相联的。第三方授权问题采用传统认证方式，若要访问业务，一定要先登录。
引言
以前对认证这方面的认识一直不太深刻，不清楚为什么需要token这种认证，为什么不简单使用session存储用户登录信息等。最近读了几篇大牛的博客才对认证机制方面有了进一步了解。
Basic Auth
这种认证直接顺应HTTP协议的无状态性，每次执行业务的时候，都暴力地附带username与password参数，并将其发送给服务器进行验证。尽管在服务器端可以优雅地使用AOP技术（如拦截器或动态代理）对所有controller进行前置的登录验证。但如果每次验证都要查数据库的话，创建连接与查询操作势必会增大开销。如果服务器端不做任何记忆（有状态性）处理的话，那么这种方式就已经没有其他办法可以优化了。
Cookie/Session Auth
上面已经点到，只要服务器端稍加一些记忆处理（记录哪些用户登录过）即可大大优化这个过程：只需要在用户第一次登录系统的时候，将对应的username放入一个类似与Set
要优雅地解决上述问题，就要得益于后来HTTP协议中出现的Cookie与Session技术了。当浏览器利用HTTP协议访问服务器的时候，服务器会为其自动创建一个其独有的session对象。session在基本的数据结构上类似于键值对Map，但不同的是它还提供了若干操作方法，且可以设置时效。既然一个浏览器唯一对应了一个session，那就好办了，用户第一次登录验证成功后，就可把用户名写入session中表征当前处于该浏览器上的用户已经登录，以后访问controller只用查session中是否有username键即可，若有放行，若没有则阻止。如下图所示：
Token Auth
目前被众多公司广泛采用的是token认证，它的认证过程都是围绕着一个名为token字符串展开的，其认证流程如下：
第一次登录
用户携带username与password请求第一次登录（为保证安全性通常采用HTTPS协议传输）；
服务器接收到后，查询数据库看用户是否存在且密码（MD5加密后）是否匹配，若匹配，则在用户表中查询该用户信息（角色、权限、状态等）；
从配置文件中读取签名的私钥，并整合上一步得到的用户信息生成token（可采用第三方库JWT lib）；
将token写入cookie并重定向到前端。
登录后访问业务
用户携带从cookie（若为移动终端，可以是数据库或文件系统）取出的token访问需登录及特定权限的业务；
请求首先被认证拦截器拦截，并获取到传来的token值；
根据配置文件中的签名私钥，结合JWT lib进行解密与解码；
验证签名是否正确（若不正确JWT会抛出异常）、token是否过期与接收方是否是自己（由自己判断）等。若通过则证明用户已登录，进入权限验证阶段；
通过权限验证框架（shiro、spring security等）验证用户是否具有访问该业务的权限，若有则返回相应数据。
1.cookie支持问题
session和cookie其实是紧密相联的。浏览器与服务器首次建立连接的时候，服务器会自动生成一个会话号sid，并写入响应报文的首部字段
可以看出cookie/session认证要求客户端必须支持cookie技术，但很显然，客户端并不是只能为浏览器，还可以是PC桌面、移动终端等其它平台，对于这些平台，我们无法保证他们都能支持cookie技术。而token认证只认token这个字符串值，至于前端是浏览器采用cookie存的token还是Android终端用数据库存的token都无所谓，只要拿到token值即可进行验证。
2.session共享问题
session是无法在多台服务器之间共享的，特别在分布式部署环境（即多台部署了同一系统的Web服务器集群）下将带来很多同步、一致性问题。比如下面这个场景：
用户请求登录，HTTP请求被转发到了服务器A，在A上完成认证后将登录状态记录到了session；
用户后续请求其他需登录的业务，HTTP请求被转发到了非A的服务器上，这时由于这些服务器上的session并非A上的session，所以其上就没有登录状态记录，所以业务操作将被拒绝！
很显然这时采用cookie/session认证就很棘手了，需要自己去维护同步、状态一致等问题。而token根本不会依赖session，所有服务器都是一致地采用私钥+解密算法分析签名的正确性。
3 时间/空间开销问题
如果session不仅是要存储用户名，还要存储时效时间、登录时间等各种状态信息（特别是大型系统），那么一旦登录的用户数激增，服务器的内存消耗也将急剧增大。而token认证是完全将状态存入了token值中，再利用加解密算法将状态取出，用时间复杂度换取了空间复杂度，内存开销大大减小，时间效率有降低。
4 第三方授权问题
采用传统认证方式，若要访问业务，一定要先登录。假如这时一个第三方应用希望获取该用户在本系统的一些资源（如头像、昵称、签名等），则一定要先接受登录拦截器认证才可放行，这时如果第三方应用也通过用户名+密码登录的形式来获取信息的话，势必会暴露用户在本系统的信息，很不安全！
而一种更巧妙的做法是，先记录第三方应用的AppID与其url地址，然后跳转到本系统登录页面进行登录，认证成功后，经本系统的认证服务器生成access_token，携带该参数并重定向到url地址所在页面。此后第三方应用即可凭借该access_token的权限范围，访问所需的本系统的资源。
可以看出，无论是本系统自己凭借token访问自己的资源，还是第三方应用凭借access_token访问本系统资源，依靠的都是token这个凭据，走的都是统一的一套流程，而传统方式，需要额外写一套，可维护性很不好。关于第三方认证文章可以参考理解Ouath2.0。
虽然token认证优势非常明显，但仍然需要考虑如下问题：如何抵御跨站脚本攻击（XSS）、如何防范重放攻击（Replay Attacks）、如何防范MITM （Man-In-The-Middle）攻击等。对此本文就不再做详细叙述了。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/43203.html
摘要：确保安全的在协议中有可能存在信息窃听或身份伪装等安全问题。与组合使用的被称为，超文本传输安全协议或。无法证明报文完整性，可能已遭篡改所谓完整性是指信息的准确度。如何防止篡改虽然有使用协议确定报文完整性的方法，但事实上并不便捷可靠。 确保 Web 安全的 HTTPS 在 HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。使用 HTTPS 通信机制可以有效地防止这些问题。 一. H...
摘要：确保安全的在协议中有可能存在信息窃听或身份伪装等安全问题。与组合使用的被称为，超文本传输安全协议或。无法证明报文完整性，可能已遭篡改所谓完整性是指信息的准确度。如何防止篡改虽然有使用协议确定报文完整性的方法，但事实上并不便捷可靠。 确保 Web 安全的 HTTPS 在 HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。使用 HTTPS 通信机制可以有效地防止这些问题。 一. H...
摘要：确保安全的在协议中有可能存在信息窃听或身份伪装等安全问题。与组合使用的被称为，超文本传输安全协议或。无法证明报文完整性，可能已遭篡改所谓完整性是指信息的准确度。如何防止篡改虽然有使用协议确定报文完整性的方法，但事实上并不便捷可靠。 确保 Web 安全的 HTTPS 在 HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。使用 HTTPS 通信机制可以有效地防止这些问题。 一. H...
摘要：是最流行的大数据处理平台之一。的兴起也招致了很多批判，并且随着安全专家不断指出其潜在的安全漏洞及大数据的安全风险，使得一直在改进其安全性。自对安全性进行重新设计以来，的安全模型大体上没发生什么变化。 本文译者：吴海星 敏感信息的安全和保护是当今人们最关心的问题之一。进入大数据时代，很多组织都在从各种源头收集数据，进行分析，并基于对海量数据集的分析做出决 策，因此这一过程中的安全问题变得愈发...
摘要：首发地址识别认证与安全第三部分的章提供了一系列的技术和机器，可用来跟踪身份，进行安全性检测，控制对内容的访问。安全使用基本认证的唯一方式就是将其与配合使用。加密之前的原始报文通常被称为明文或。 WilsonLius blog 首发地址 识别,认证与安全 第三部分的4章提供了一系列的技术和机器，可用来跟踪身份，进行安全性检测，控制对内容的访问。 客户端识别与cookie机制 第十一章 H...
阅读 2843·2021-11-02 14:40
阅读 709·2019-08-30 15:53
阅读 1136·2019-08-30 15:53
阅读 3150·2019-08-30 13:53
阅读 3181·2019-08-29 12:50
阅读 1023·2019-08-26 13:49
阅读 1730·2019-08-26 12:20
阅读 3514·2019-08-26 11:33
