​
token的简介和生成校验已经在前面的博客进行过分享，有需要的小伙伴可以先进行回顾。

传送门：token介绍，以及如何生成以及校验token

文章目录

• 前言：
• 场景一：网吧计时
• • 场景分析：
  • 对token的要求：
  • 实操：
  • 总结：
  • • 优点：
    • 缺点：
• 场景二： Esxi系统页面、jumpServer
• • 场景分析：
  • 对token的要求：
  • • 实操：
  • 总结：
  • • 优点：
    • 缺点：
• 场景三：微信、支付宝等app
• • 场景分析：
  • 对token的要求：
  • 总结：
  • • 优点：
    • 缺点：
• 场景四：语雀等pc应用程序（双token）
• • 场景分析：
  • • • 解决方案：双token
  • 对token的要求：
  • 总结：
  • • 优点：
    • 缺点：
• 场景五：提升响应速度（redis）
• • 场景分析：
  • 对token的要求：
  • • 实操：
    • • redis工具类
      • 验证redis校验速度
  • 总结：
  • • 优点：
    • 缺点：
• 思想升华：

前言：

  Token最常见的应用场景之一就是身份验证。在传统的身份验证方式中，用户需要输入用户名和密码才能登录系统，这种方式容易被破解和盗用。而使用token方式进行身份验证，可以有效防止用户身份信息被盗用。

  当用户进行身份验证后，服务器会生成一个token并将其返回给客户端，客户端可以使用token来访问受保护的资源，而不需要重新输入用户名和密码。这种方式不仅可以提高安全性，还可以提高用户体验。

场景一：网吧计时

场景分析：

  严格规定登陆时长，超时则跳转登陆页面，必须重新输入密码才能继续使用

对token的要求：

  登陆成功后，服务器生成的token需要携带时间戳（token时间戳=当前时间+有效时长），后台定制一个有效期时长，在网吧计时收费场景中有效范围就是可以上机的时长。

  每次请求都要校验token是否过期（ 时间戳是否小于现在时间）

  token也只用存在浏览器缓存即可，减少服务器端的存储压力。

实操：

javaWebToken为例：

                com.auth0        java-jwt        3.8.2                org.apache.shiro        shiro-core        1.8.0                org.apache.shiro        shiro-web        1.8.0    

         public static String getToken(String userPhone) {        try{            //从当前时间算起，再加上有效时长30分钟            Date date = new Date(System.currentTimeMillis() + 30*60*1000);            //用秘钥生成签名            Algorithm algorithm = Algorithm.HMAC256('P1ooisyGFJhgzrctMOofvaHLuiNFOmktedw');            //默认头部+载荷（手机号/id）+过期日期+签名=jwt            String jwtToken= JWT.create()                    .withClaim("userPhone", userPhone)                    .withClaim("userId", "xxxxxxx")                    .withExpiresAt(date)                    .sign(algorithm);            return jwtToken;        }catch (Exception e){            log.error("用户{}的token生成异常：{}",userPhone,e);            return null;        }    }

验证token有效期：

    // 判断 token 是否过期    public static String isExpire(String token) {        DecodedJWT jwt = JWT.decode(token);//解码token        // 如果token的有效期小于当前时间，则表示已过期，为true        boolean isExpire = jwt.getExpiresAt().getTime() < System.currentTimeMillis();        if(isExpire){           return jwt.getClaim("userPhone").asString();//获取token携带的数据        }else{            return null;        }    }

拦截请求，开始验证token

public class JwtToken implements AuthenticationToken {        private String token;    public JwtToken(String token) {        this.token = token;    }    @Override    public Object getPrincipal() {        return token;    }    @Override    public Object getCredentials() {        return token;    }}@Componentpublic class ShiroRealm extends AuthorizingRealm {        @Override    protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken auth) throws AuthenticationException {        try{            String token = (String) auth.getCredentials();            String userPhone=JwtUtil.isExpire(token);            return new SimpleAuthenticationInfo(userPhone, token, getName());        }catch(Exception e){            throw new AuthenticationException("验证token失败");        }    }}

总结：

优点：

• 严格规定登陆时长，简单来说就是安全性高。
• 代码逻辑简单，token过期了就重定向到登陆页面，不需要做延时等处理。

缺点：

• 时间一到就跳转到登陆页面，对用户来说非常突然，某种程度上说用户体验非常不好。
• 用户有可能停留在页面不做任何操作，因此客户端必须定期主动的给服务器发请求（或使用消息队列），以便及时发现校验token过期。

场景二： Esxi系统页面、jumpServer

场景分析：

  Esxi系统页面、jumpServer的web终端页面等，超过一段时间内不操作（例如0.5小时）自动退出登录，再想继续操作需要重新登录。

对token的要求：

  和场景一类似，区别是增加了一个判断：每次请求都会判断token是否快要过期（例如设置token还有10分钟过期）。

  如果将要过期，则重置token有效期（服务器发个新token给客户端）；如果已经过期，需要重新登录。

实操：

  重新生成一个新的token，前端收到新的token后把旧token丢弃（前端代码略）

总结：

优点：

• 用户一直在使用页面，token就会被一直重置，对活跃用户友好。
• token有效期短，人离开一段时间就无法继续使用软件，这个设计安全性较高。
• 用户在token过期后再次操作才会要求再次登陆，也就是说，不需要客户端时时给服务器发消息验证token是否有效，减少网络开销。

缺点：

• 如果有效期设计的短，用户操作也不频繁的情况下，会导致用户频繁登陆，体验较差。合理设置有效期非常重要。

场景三：微信、支付宝等app

场景分析：

  微信、支付宝等手机app，我们一旦安装并登陆以后，除了涉及资金或信息安全的场景需要输入一些密码，基本上我们打开app就能用，不会让我们重复登陆。

对token的要求：

  token有效期设置的很长（3个月、6个月、一年等）

  每次请求还是会验证token有效期，但如果token过期，则发消息给客户端。

  客户端收到消息以后，给服务器发送重置token的请求。

总结：

  适用于安全性有保证的场景（例如手机App：手机有锁屏码等安全机制，涉及到金钱等重要信息还有其他验证方式）

优点：

• 用户只需要登陆一次，用户体验很好

缺点：

• 客户端可以发送重置token的请求，故token一直有效，手机锁屏被破解，任何人都能使用，也是个安全隐患。
• 只用登陆一次，用户很有可能忘记密码，想要避免用户体验差，必须绑定手机号，支持验证码登陆。

场景四：语雀等pc应用程序（双token）

场景分析：

  场景四和场景二类似，区别是用户长时间不使用的情况下才会被强制用户登录。

  例如“语雀”等应用程序，长时间不使用是会被要求重新登录的。

  我们每个人都安装过一些使用频率不高的软件，这些软件在产品设计时就决定了用户的使用频率和周期，那他们是如何界定“一直在使用的活跃用户”和“长时间不使用的非活跃用户”呢？

  还是靠设置token有效期，有效期设置的长一些，例如3个月或6个月不使用才算非活跃用户。

  但是如何沿用场景二的token要求，设置有效期长的token，会留下很大的安全隐患：token一旦被黑客截获后长时间可以被使用，还不会被服务器察觉。

解决方案：双token

  什么是双token？以现有的短token的基础上再增加一个长token，形成两个token校验有效期的模式。

  短token可以防止被截获后无休止使用，所以还要使用有效期短的token用来验证有效期。

  而新增加的长token，它的有效期用来区分“活跃用户”和“非活跃用户”，用来实现短token过期后，活跃用户系统自动给重置token，非活跃用户需要重新登录。

对token的要求：

  用户登录成功后，服务器生成一短一长两个token返回给客户端，客户端每次请求服务器携带的是短token。

   如果服务器发现短token过期，则通知给客户端，此时客户端携带长token给服务器校验。

  如果长token未过期，表示用户为“活跃用户”，服务器重置短token和长token发给客户端。
  如果长token过期，表示用户为“非活跃用户”，用户需要重新登录。

总结：

优点：

• 帮助使用频率不高的软件区别“活跃用户”和“非活跃用户”，提升“活跃用户”的体验，保证“非活跃用户”的信息安全

缺点：

• 刷新token期间，原有的token不能用，在并发情况下会导致其他问题。

场景五：提升响应速度（redis）

场景分析：

  场景一到四的共同点：①token内置了时间戳，②服务器端不存储token
  场景五是对以上以上四个场景在验证速度上的优化，亲测使用redis可以提高2-4倍的验证速度。

对token的要求：

  token内不设置时间戳，而是将token存在redis中（例如：键为token，值为用户信息），并设置token存在redis中的保存时间。

  客户端仍然保存着token，每次请求都携带token。服务器接到请求，把token当做键去redis中拿数据：

  如果能拿出数据，则说名token没过期，如果拿不到，则说明token过期了。

  想要重置token有效期，直接根据键重置数据在redis中的有效期。

实操：

                            org.springframework.boot            spring-boot-starter-data-redis            3.0.0        

redis工具类

@Componentpublic final class RedisUtil {    @Autowired    private RedisTemplate redisTemplate;        public String get(String key) {        return key == null ? null : (String) redisTemplate.opsForValue().get(key);    }        public long getExpire(String key) {        return redisTemplate.getExpire(key, TimeUnit.SECONDS);    }            public boolean hmset(String key, Map map, long time) {        try {            redisTemplate.opsForHash().putAll(key, map);            if (time > 0) {                expire(key, time);            }            return true;        } catch (Exception e) {            e.printStackTrace();            return false;        }    }}

拦截请求，开始验证token

public class ShiroRealm extends AuthorizingRealm {    @Autowired    private RedisUtil redisUtil;        @Override    protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken auth) throws AuthenticationException {        //不使用token验证来校验token是否可用，改成把token存redis中，在redis中设置数据有效期        String token = (String) auth.getCredentials();        if (StringUtils.isEmpty(token)) {            throw new AuthenticationException(Constant.TOKEN_EXPIRED);        }        //判断是否能从redis中用token拿到过期时间        try{            Long times=redisUtil.getExpire(token);            //如果还有0.5小时过期，就刷新token在redis中的有效时间(有效期设置为2小时)            if(1800>times){                redisUtil.expire(token,7200);            }            String userId =redisUtil.get(token);  //获取key中的用户id            return new SimpleAuthenticationInfo(userId, token, getName());        }catch(Exception e){            throw new AuthenticationException("验证token失败");        }    }}

验证redis校验速度

       //token时间戳校验       long startTime=System.currentTimeMillis();   //获取开始时间       for(int i=0;i<99;i++){           String userPhone = JwtUtil.isExpire(token);       }       long endTime=System.currentTimeMillis(); //获取结束时间       System.out.println("用时间戳方式校验100次token是否有效： "+(endTime-startTime)+"毫秒");

       //redis校验       long startTime=System.currentTimeMillis();   //获取开始时间       for(int i=0;i<99;i++){           if(StringUtils.isEmpty(redisUtil.get(token))){               return null;           }       }       long endTime=System.currentTimeMillis(); //获取结束时间       System.out.println("用redis设置过期时间方式校验100次token是否有效： "+(endTime-startTime)+"毫秒");

​​​​

总结：

优点：

• 服务器生成了token就直接存到redis中，token是不会被拦截篡改的，因此默认token是正确的，也就减少了验证token是否正确这一步骤
• 重置了token，token本身也不会变，减少客户端处理废弃token、再存储新token的逻辑
• redis的数据存在内存中，IO速度快

缺点：

• 依赖第三方软件，需要搭建redis服务器，考虑到redis挂了软件也不能使用，还要搭建redis集群

思想升华：

  每种设置token有效期的方案都有对应的场景，抛开场景谈方案是狭隘的。再学习计算机的过程中，我发现无论是磁盘调度方式、内存存储方式、raid0-6，所有方式方法的诞生都和当时的场景相关，并且往往在时间和空间上面进行取舍。所以没有最优的方案，只有当下相对合适的方案。

觉得有用就点个赞吧！

​