大家好，今天小编来为大家解答APP服务端接口，用jwt还是用redis和token，分别有什么优势这个问题，分布式token为啥不建议存在redis很多人还不知道，现在让我们一起来看看吧！
本文目录
- token有必要存数据库吗
- 不依赖第三方存储，用RSA加密解密来实现token验证，怎么用算法实现token只能用一次
- APP服务端接口，用jwt还是用redis和token，分别有什么优势
- 分布式技术给开发者用的还是给用户的为什么
token有必要存数据库吗
token不要放在数据库。token一般作为用户登录认证完成后产生的id，作为后续访问请求的凭证，有一定的时效性，一般都小于用户登录态存在的时长，服务请求过程中会频繁的查询验证，所以token最好的存储方式是缓存，比如存放在redis中，设置失效时间，既满足高性能查询的需求，也满足了定期失效的功能。
不依赖第三方存储，用RSA加密解密来实现token验证，怎么用算法实现token只能用一次
对于一些安全性要求高的系统或者请求一些受保护的资源时，我们要进行鉴权，以判断此次请求是否是被允许的，这里我们就会用到Token机制。Token是由服务器端签发给客户端的，出于性能开销的考虑，一般情况下的Token在一段时间范围内是可以反复使用的，如果你想实现同个Token只能使用一次，也是有方案的。
Token是什么？为什么要使用Token？Token是令牌的意思，一般在登录系统、API认证、密保、邀请码中被广泛使用，它是由服务器端产生的。
Token工作流程大概是这样：
调用方使用用户名及密码向服务器端进行请求认证；
若服务器端认证成功，则生成唯一的Token并返回给客户端；
客户端下次请求任何资源时都会把Token带上，交给服务器端进行权限鉴证，以此来证明此次请求的合法性。
这种机制是不是和Session/Cookie很像？那为什么要用Token呢？原因很简单：
Token具有无状态性，适用于分布式系统，可在多个服务间共享；
Token可避免CSRF攻击；
Token能避开同源策略的限制等。
同个Token只能使用一次的实现方案1、借助Redis来控制Key失效时间（实施成本低，推荐此方法）
我们可以把Token作为Redis中的某个Key，同时设置TTL，当此Token使用过一次后就删除Redis中对应的Key即可。
2、Token重新签发（存在性能问题）
一个Token原始数据（加密之前的数据）中应包含一个时间戳，当服务器端拿到客户端传递过来的Token时先判断是否合法，若合法则解析Token，拿出里面的数据，将时间戳改为当前，然后重新计算生成新的Token并返回给客户端。
这种方法虽很安全，但考虑到RSA等加密也是要消耗CPU性能的，这块需要综合考虑。
以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流~我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！APP服务端接口，用jwt还是用redis和token，分别有什么优势
jwt属于无状态设计，用户登陆的信息关键存放在jwt加密数据里，这种设计下服务器不需要存储jwt密文，只需要解密就能拿到授权信息等用户信息。这种设计是一种利用计算力减少token设计下数据库及缓存的压力和设计复杂度，因此它的本质就是不存储登陆授权，而通过密文本身保存授权信息。
token加redis设计，是一种登陆后分配随机token，然后记录token与用户信息对应关系的设计。
很明显，这两张设计的区别就在于token实际上是需要服务器存储，每次验权需要查询数据库。jwt不需要服务器存储，信息本身就存储于jwt本身，这种模式无需使用数据库。
但是这种流行的jwt有一个设计上的缺陷，他通过密文传输用户信息，那么服务器在这种基础结构下是无法做到关闭用户登陆授权的操作，如果用户的jwt密文被偷窃，那么黑客就能以用户身份登陆，并且即使知道密文丢失，也无法关闭被偷窃的jwt密文。为了应对这一问题，可以使用jwt内部验证有效期和jwt黑名单模式，但是有效期始终无法做到及时停止jwt授权，这是一个治标不治本的方法。而jwt黑名单模式，则需要数据库或内存存储黑名单，那么，这实际上违背了jwt的免数据库设计原则。
因此，如果严格按照两种模式设计，jwt更适合低安全级别的服务器设计，如普通的博客、阅读器等等，这种服务允许不严格的登陆授权，即使密文丢失也不会造成用户的严重损失，却能获得较高的服务性能。
token模式，必须配合数据库进行存储和查询，因此性能较低，但token模式却能做到及时的授权关闭，已经登陆授权可见可查，每一次token都会有对应的记录。因此token模式适合较高安全度和用户登陆等信息分析的系统，如政府系统，支付系统等不可能允许高权限的token被偷窃却不能及时关闭授权。
jwt，适合轻量的系统和权限不严格系统。
token，适合重量系统和权限有严格要求的系统。
谢谢大家的阅读和头条的推荐，我再来详细的和大家讨论下这两者在实现上的区别，这样大家可能更方便的理解这两个不同的概念。
我们讨论的这两种方式只限于规范实现，如果有其他优化或者衍生设计模式则不在讨论之内。
token：
普通的token方式采用的是：登录-->生成随机字符串（token）-->服务器保存token与用户信息的对应关系
对应用户利用token校验的流程是token-->查询token对应用户信息-->各系统根据用户信息进行业务处理。
很明显可以看出，token模式下的字符串实际上不需要和用户信息有任何关联，生成的token字符串的要求就是唯一，不能被其他用户占有，否则就会出现用户登录后实际上是以其他人身份进行业务处理。如果字符串是随机生成，那么黑客就无法猜测token的生成规律，也无法从token直接猜测到用户相关信息。
jwt:
jwt采用的生成：登录-->生成带有用户数据的加密字符串（该字符串服务器并不存储，直接下发给客户端）
校验：客户端将存储的jwt密文带上-->服务器解密密文，获取到用户信息
可以看出，jwt的凭证不仅要求唯一，还要求密文本身实际上是带有了用户信息，当然这块可以是非敏感信息，这只是实现上的细节区别，和结构本身没有特别大的关联。服务器本身并没有存储这次jwt密文，每次服务器的处理都是直接解密jwt密文。这样做的好处就是服务架构内直接抛弃了登录相关的传统token系统，并且服务器不再管理登录状态，token有效状态等问题。
而jwt带来的问题，凭证实际上的一串密文，更多的用户信息或session信息需要更大的密文来存储，进而每次请求都带上jwt就会使网络传输的内容变大，加大了网络开销；凭证是一串密文，那么如果黑客破解了服务器的加密方式，那么密文实际上就是用户信息在网络上传输，黑客可以直接伪造jwt登录或通过jwt密文获取到用户信息；jwt本身不管理jwt的有效性，一旦密文被偷窃，无法做到关闭掉黑客的授权。
分布式技术给开发者用的还是给用户的为什么
分布式技术明显是给开发人员需要熟悉的。分布式就类似咱们拼装零件一样，最后组成汽车，但是各个系统之间需要协作，共享，来分担系统的压力，共同的配合让系统更快更好的运行。
OK，关于APP服务端接口，用jwt还是用redis和token，分别有什么优势和分布式token为啥不建议存在redis的内容到此结束了，希望对大家有所帮助。