面试中被嘲笑Token放在redis里，该如何应对这种情况呢？
你就问他代码上线前有没有做review，有没有做灰度发布、蓝绿发布，每次上线有没有做回归测试，有没有定期做渗透测试、漏洞扫描，安全漏洞有没有做定期修复，生产环境有没有做网络隔离（划分DMZ、内网），有没有准入控制，程序配置文件中密码字段有没有加密，敏感数据落盘（包含日志、数据库）有没有做脱敏和加密。
如果他们公司有一条没做到，就怼他: 垃圾公司。
如果他们公司都做到了，那你的确无话可说。
现在主流的Token方案主要是两种
第一种是传统的cookie/session方案，工作原理就是服务器生成一个随机会话ID, 并下发给客户端，此方案简单，但是对于分布式、多副本需要用例如redis、mysql之类的服务进行数据共享。直接存token不是什么大问题，但是如果遇到数据库数据泄露可能会导致攻击者通过token登陆到后台，解决方案有很多，比较简单的做法就是存token的hash值，这样可以避免因数据泄露导致的身份伪造。
第二种就是jwt方案，此方案最大优势就是无状态，不用保存会话信息就可以实现分布式、多副本。但缺点是没有会话列表以及吊销会话困难。如果有人token被泄露了，要么等token过期，要么修改jwt密钥让所有会话失效。想要解决此问题，通常就需要引入redis、mysql之类的服务存储token信息，可以将所有已登陆的token信息存入数据库，吊销时删除相关token信息，也可以建立token黑名单，将吊销的token信息存入此黑名单。但是直接存入完整token也可能存在方案一类似的风险，解决方案存hash或者是在payload中插入一个tokenid字段，数据库只记录id字段，这样就可以避免因数据泄露导致的身份伪造。
对于token直接入库我没有任何否认的意思，每个公司/项目所需要的安全程度不一样，你们项目如果能接受这个风险，完全可以直接入库。我提到的存token的hash或jwt的tokenid，只是基于存在的风险点，提供了一点建议。存token还是存hash，无非就是一行代码的事情。
如果你秉着技术探讨的态度说token入库完全没有风险，那我可以给你探讨探讨，否则，可以忽略我的论点：
按照问题中所说的token放redis，从安全角度来说：
- 我们不能保证所有维护的人都能有这个觉悟，保证redis只能内网访问，并且都有强口令保护，恰好我们公司另一个团队，以前就出过这样一个事情：redis直接允许公网访问，密码还是弱口令，结果服务器遭挖矿，数据倒是没有泄露。这样的事情我在很多技术群（QQ群）里，看到类似的案例。
- 我们不能保证redis所在的内网，都拥有固若金汤的防火墙规则。恰好我们公司另一个团队又出过类似的事情，为了方便调试把服务器的docker远程控制端口开放到公网，还不需要任何认证就可以使用，结果也惨遭挖矿。如果黑客当时通过横向渗透，我相信可以拿下其他一些服务器的权限，因为很多公司（包括我们公司），内网之间的防护做的并不是特别安全，拿下redis服务器权限也不是不可能。
- 你没法保证你们开放到公网的所有服务都绝对安全，例如以前的fastjson漏洞，或者你的程序存在SQL注入漏洞、任意命令执行漏洞等。
或许你认为你不会存在这些问题，但你不能保证你没有猪队友。
你或许会认为出现问题再修复，只要不是你的token自身的问题就不归你管。那我只能说，想法没错，继续保持。
