jwt与token+redis,哪种方案更好用?_jwttoken优点与缺点

由网友 DylansLife 提供的答案：

jwt与token+redis是两种常见的无状态认证方案,它们各有优缺点,适用于不同的场景。

jwt是一种基于JSON的开放标准,用于在双方之间安全地传输信息。jwt由三部分组成：头部、有效载荷和签名。头部包含了加密算法和令牌类型；有效载荷包含了一些声明,如用户标识、过期时间等；签名是对前两部分的加密,用于防止篡改。

token+redis是一种基于令牌和缓存的认证方案,用于在服务端存储用户信息和状态。token是一个随机生成的字符串,用于标识用户身份；redis是一个高性能的内存数据库,用于存储token和用户信息的映射关系。

jwt与token+redis的对比如下：

• jwt的优点是去中心化,不需要在服务端存储用户信息,减轻了服务器压力,便于分布式系统使用；缺点是一旦下发,服务端无法主动让token失效,如果发生token泄露,服务器也只能任其蹂躏,在其未过期期间不能有任何措施。另外,jwt的请求头体积较大,加解密效率也较低。
• token+redis的优点是服务端可以主动让token失效,可以实现注销登录、踢人下线等功能；缺点是依赖内存或redis存储,分布式系统的话,需要redis查询/接口调用增加系统复杂性。另外,token+redis需要维护会话状态,与RESTful原则相悖。

综上所述,jwt与token+redis哪种方案更好用,要根据具体的业务需求和场景来决定。如果对用户管理要求比较严格,或者需要实现一些会话相关的功能,可以使用token+redis方案；如果对用户管理要求比较宽松,或者需要实现一些无状态的功能,可以使用jwt方案。

由网友 夕阳雨晴 提供的答案：

1. 问题描述

jwt与token+redis,哪种方案更好用？

问题结论

刚好最近有项目使用了jwt,而且是定制化的jwt的认证机制,就个人的理解而言,各自有其优缺点,并且针对不同的场景需要进行约束性开发,如用户剔除、同一用户每2h只生成一次jwt等。

2. Token机制简述

2.1 Token的用途

• 用户在登录APP时,APP端会发送加密的用户名和密码到服务器,服务器验证用户名和密码,如果验证成功,就会生成相应位数的字符产作为token存储到服务器中,并且将该token返回给APP端。

• 以后APP再次请求时,凡是需要验证的地方都要带上该token,然后服务器端验证token,成功返回所需要的结果,失败返回错误信息,让用户重新登录。其中,服务器上会给token设置一个有效期,每次APP请求的时候都验证token和有效期。

在存储的时候把token进行对称加密存储,用到的时候再解密。文章最开始提到的签名sign：将请求URL、时间戳、token三者合并,通过算法进行加密处理。

2.2 token+redis机制

• 用户验证通过后,服务端通过如uuid相关的方法,生成token,存储用户信息。
• 当请求服务时,客户端将token带上来,进行查询验证,如token存在并在有限期内,请求有效,否则请求非法。

token + redis机制是中心化的,每次验证token有效性时,都需要访问redis,其核心优点实服务端可以主动让token失效,缺点是每次都要进行redis查询。占用redis存储空间。

2.3 jwt机制

这是一种无状态身份验证机制,因为用户状态永远不会保存在服务器内存中。 服务器受保护的路由将在授权头中检查有效的JWT,如果存在,则允许用户访问受保护的资源。 由于JWT是独立的,所有必要的信息都在那里,减少了多次查询数据库的需求。

• Java jwt普遍选用java-jwt工具包依赖,gradle依赖：compile ‘com.auth0:java-jwt:3.2.0‘
• 用户发起登录请求,验证通过后,服务端创建一个加密后的JWT信息,作为Token返回。在后续请求中JWT信息作为请求头,发给服务端。服务端拿到JWT之后进行解密,正确解密表示此次请求合法,验证通过；解密失败说明Token无效或者已过期。

jwt的有点主要有：a.其是去中心化的,便于分布式系统使用； 2. 基本信息可以直接放在token中。 user_id,session_id； 3. 功能权限信息可以直接放在token中。用bit位表示用户所具有的功能权限。 其缺点有：服务端无法主动让token失效,另一个是无法很好的控制payload的数据量。

3. 小结

jwt和token+redis两种方案,没有最优,只有结合不同的业务场景,需求最适合的方案。就比如token 2h过期,同一用户每1.5h只生成一次token,当两次token并存时,同时有效。大家可以考虑在这两种方案的前提下,分别如何实现？

作者：夕阳雨晴,欢迎关注我的Html369号：偶尔美文,主流Java,为你讲述不一样的码农生活。

由网友 Ex无毁湖光 提供的答案：

为什么不用jwt+redis？

思路其实和token那个差不多

生成时把两个token（访问token和刷新token）都存redis,刷新过后把之前的访问token丢redis的黑名单里,生成的时候刷新token还在有效期内就生成一个访问token。

举例子：

访问只能用访问token,时间假设30分钟,刷新token假设30天,只能用于重新获取访问token。

第一次访问：

获取两个token,并存入redis中。

第二次访问：

只使用访问token,当访问token有效时间在1分钟以内时,刷新token,获取一个新的token,刷新时把老访问token丢黑名单,时效一分钟。

修改密码退出登录等：

同理检查黑名单,在黑名单里直接就不解析token是否有效,直接返回无效token就行。只要刷新就把以前的token丢黑名单,刷新时,刷新token作为访问接口的token,老token作为传递的凭证,防止疯狂刷新导致你的redis黑名单无限增长。

这样有一个好处,你不用频繁的访问数据库来判断token是否有效,只需要计算jwt是否有效和配合redis来维护有效的token

由网友 猿狮兄 提供的答案：

两种方式的优缺点你在问题中说的很清晰,适用的系统根据实际场景我觉得不难分析。以下为我自己的一些思考。

在拥有庞大用户量的系统中,用户保持登录态仅作为跟踪分析用户行为,不会对账户本身造成过大影响。那么我认为它的登录剔除操作不重要,我也不允许它不断的为校验用户来刷我的库甚至redis,用jwt很合适。

预警系统对行为上报异常账户进行监测,只监测一批异常用户,我需要知道它的实时状态,随时准备token失效,那么token+redis就有必要了。

一般的通用系统,我推荐的采用jwt+redis的组合方案。jwt进行认证,redis作为证书撤销列表(CRL)来使用,也就是黑名单。

从通用系统出发,认证是个频繁操作,几乎每次的请求都需要获取登录认证数据,在令牌有效范围内进行拉黑,这样的令牌正常跟用户量来比较,为数不多。

具体认证方案步骤如下:

step1:用户登录,验证通过,由认证服务器jwt方式签发token,时效30分钟。

step2:用户行为,jwt验证通过,CRL中token不存在,向后执行coding…

step3:发现用户异常,用户token写入CRL,时效30分钟。这样可以保证签发的token可以在有效期内一直被拉黑。

step4:用户行为,jwt通过,CRL不通过,重新登陆或者其他业务逻辑。

对比单纯jwt方式,组合方案会多出一次redis请求,这样对分布式的登录验证有一定的破坏,增加了一次网络开销,需要根据业务预计的黑名单换入换出频率和黑名单总容量来评估使用这种方案是否合适。

对比单纯token+redis方式,组合方案用一次jwt摘要算法(通常一次本地SHA256)来替换一次查库校验,信息的实时性不强,不是每次获取最新信息,但是速度会快,用本地的一次计算减少最少一次网络IO,数据查询,给数据库的压力也会大减,注意保存好私钥。

解决方案可以多种多样,我们也可以从其他方向寻找灵感,例如OAuth2,PKI/CA 体系证书的验证。一个实现方案+配套系统的配合就可以打造出想要的效果。

欢迎随时讨论。

由网友 格物信息 提供的答案：

JSON Web Token（JWT）和基于Token+Redis的认证方案都是常用的Web应用程序认证方案之一。虽然它们都可以用于保护Web应用程序,但它们在工作方式、优缺点和适用场景等方面有所不同。下面,我们将分析这两种认证方案的优缺点,以便您选择最适合您的应用程序的方案。

JWT认证方案

JWT是一种开放的标准,用于在网络应用之间安全地传输信息。在JWT认证方案中,当用户进行身份验证时,服务器将使用密钥为其生成一个JWT令牌,并将其返回给客户端。这个JWT令牌包含了用户的身份信息,并通过数字签名进行了保护。以后,当客户端向服务器发出请求时,它将携带这个JWT令牌,并将其解码以验证用户身份。

优点：

1. 无需在服务器上存储会话状态。
2. 可以轻松地扩展到多个服务器。
3. 安全性高,JWT令牌只能由服务器端进行修改。
4. 跨平台和跨语言支持,可以在不同的语言和平台上使用。

缺点：

1. 不能禁用一个已经发出的令牌。
2. 令牌大小可能会很大,因为它包含了用户的身份信息。
3. 可能需要更复杂的逻辑来清除过期的令牌。

Token+Redis认证方案

在基于Token+Redis的认证方案中,当用户进行身份验证时,服务器将生成一个随机的令牌,并将其存储在Redis数据库中。这个令牌将返回给客户端,并存储在客户端的Cookie中。以后,当客户端向服务器发出请求时,它将携带这个令牌,并将其与Redis中存储的令牌进行比较以验证用户身份。

优点：

1. 可以轻松地禁用一个已经发出的令牌。
2. 可以轻松地清除过期的令牌。
3. 令牌大小相对较小,因为它只包含一个随机生成的字符串。

缺点：

1. 需要在服务器上存储会话状态。
2. 可能会对服务器性能造成影响。
3. 可能需要更多的编码和逻辑来实现。

结论

JWT和Token+Redis都是常用的认证方案,它们都有其优点和缺点。如果您的应用程序需要跨语言和跨平台支持,或者需要无状态的认证方案,则JWT可能是更好的选择。如果您需要更好地控制已发出的令牌,并且您愿意在服务器上存储会话状态,则基于Token+Redis的认证方案可能更适合您的应用程序。最终,您需要根据您的应用程序的具体需求和预算来选择最适合您的认证方案。

由网友 截图那小子来了吗 提供的答案：

JWT和Token+Redis都是常用的身份验证和授权方案,它们各有优缺点,具体使用哪种方案需要根据具体的应用场景来决定。

JWT的优点：

1. 无状态：JWT是一种无状态的身份验证方案,不需要在服务器端存储会话信息,能够有效地降低服务器端的负担。

2. 安全性：JWT使用数字签名保证了身份验证的安全性,防止了数据被篡改和伪造。

3. 跨平台：JWT使用标准化的JSON格式,能够在不同的平台和编程语言之间进行传递和解析。

JWT虽然是一种非常流行的身份验证和授权方案,但是它也存在一些缺点,包括以下几点：

1. JWT不支持注销：JWT一旦颁发,就无法撤销或注销,因为JWT是一种无状态的身份验证方案,服务器端不会存储会话信息。如果需要实现注销功能,需要在客户端和服务器端之间进行额外的通信和处理。

2. JWT的安全性依赖于密钥管理：JWT的安全性依赖于密钥的保密,如果密钥泄露,可能会导致身份验证的信息被篡改或伪造。因此,密钥的管理和保护非常重要,需要采取安全的措施来保护密钥。

3. JWT的体积比较大：与其他身份验证方案相比,JWT的体积比较大,包含了较多的信息和元数据,可能会影响网络带宽和响应速度。

4. JWT不适合存储敏感信息：由于JWT是一种基于Base64编码的字符串,因此它并不适合存储敏感信息,例如密码等,因为这些信息可能会被中间人攻击者窃取。

Token+Redis的优点：

1. 高效性：使用Token+Redis方案,可以将Token存储在Redis中,能够大大提高身份验证的效率和速度。

2. 灵活性：Token+Redis方案可以根据具体的业务需求进行定制和扩展,能够满足不同的应用场景和需求。

3. 可扩展性：Token+Redis方案可以通过分布式部署来提高可扩展性,能够应对大规模应用场景的需求。

使用Token+Redis方案也存在一些缺点,包括以下几点：

1. 安全性问题：如果Token泄露,可能会被攻击者利用进行非法操作。因此,需要采取安全措施来保护Token的安全性,例如加密、签名等等。

2. 数据一致性问题：如果Token存储在Redis中,可能会出现数据一致性问题,例如Redis宕机等情况。因此,需要采取数据备份、数据同步等措施来保证数据的一致性。

3. Redis的性能问题：如果使用Token+Redis方案,需要考虑Redis的性能问题,例如Redis的并发能力、内存管理等等。如果Redis的性能不足,可能会影响系统的性能和稳定性。

4. 可扩展性问题：如果应用需要进行横向扩展,需要采取一些措施来保证Token的一致性和可用性,例如采用分布式缓存、负载均衡等等。

综上所述,需要根据具体的应用场景来选择哪种方案更适合自己的应用。如果应用需要无状态、安全、跨平台的身份验证方案,那么JWT更适合；如果应用需要高效、灵活、可扩展等方面的身份验证方案,那么Token+Redis会更好用。

由网友 functionly 提供的答案：

其实有个最本质的区别,就是过期时间。

1. JWT 假如小明拿到签发的 token,这个 token 不小心被别人拷贝走了。那么,服务端没办法撤销这个 token。只能有一个办法,服务端重置签名密钥,但是,这样导致签发的所有 token 失效。总起来,JWT 简单,省资源,分布式认证还是不错的,关键是保护好 token。
2. redis + token 如果出现上面情况,服务端只要重置小明 token 就行了,不影响其他 token。分布式环境,需要访问中心化的 redis,往返 io。

由网友 苏州知府 提供的答案：

JWT和token+redis都是常见的身份验证和授权方案,它们各有优缺点,具体使用哪种方案需要根据具体情况而定。

JWT（JSON Web Token）是一种开放标准（RFC 7519）,用于在网络应用之间传递声明。它通过数字签名来验证和信任信息,并且可以自包含信息,不需要在服务端存储状态。JWT本身的数据已经经过编码和签名,不需要再加密处理,因此其密钥越小越好。

Token+Redis方案则需要在服务端存储状态,具体实现方式为将生成的token存储在Redis缓存中,并设定一定的过期时间。当用户请求时,服务端会根据token在Redis中查找对应的信息,来判断用户的身份和授权。

两种方案各有优缺点,需要根据实际场景选择：

• 对于小规模的应用或者需要实现单点登录（SSO）的场景,JWT可能更加适合。因为它不需要服务端存储状态,使用起来更加简便。但是,JWT也有一些缺点,比如无法主动撤销令牌,需要等待令牌到期或者手动撤销。
• 对于需要更加安全的场景,比如需要主动撤销令牌、动态更改权限等,Token+Redis方案可能更适合。因为它需要服务端存储状态,可以更灵活地控制用户的权限。但是,Token+Redis方案也会增加服务端的存储压力,需要对缓存进行一定的管理。

因此,具体使用哪种方案需要根据实际情况来决定,一般情况下可以综合考虑安全性、灵活性和便捷性等因素。

由网友 偶尔来逛逛随便来瞧瞧 提供的答案：

其实在生产中,两者都离不开。jwt的优缺点很明显,优点是无状态,无需存储。因此对分布式应用来说,性能好。加上可以携带部分负载,省了许多的数据库连接。但由于他的不可撤销,很容易被人用来重放攻击。因此在生产中,jwt主要用于身份验证,以及携带部分非隐私性的数据。如果在进行如资金操作之类安全性要求较高的场景时,通常会使用验证码等二次密码手段,以redis加token进行更进一步的检验。两者是要相互结合的。当然对一些一般的应用jwt足够了

由网友 编程老妖 提供的答案：

从使用角度来说,没嘛区别,都是为了解决session共享的问题。我觉得,token+redis从安全性上比jwt要高些,jwt存在信息泄露的可能性。token+redis中的token不具有现实意义,但也最好加密后再发到前端。