JWT 确实不可控制，且在到期前无法控制失效(原生方法)，但是 JWT 也带来了一些好处，比如分布式会话，当然， Session 也可以实现，但是 JWT 天生就支持。
就问题而言，你可以在 JWT 的基础上进行扩展，配合 Redis 实现 Token 黑名单机制来让指定的 Token 失效，来弥补这个问题。
当然，这样看来还是不划算的，但是对效率来说并不会影响太多。
接着来说避免被截获问题，无论是 JWT 还是传统 Session (寄存于 Cookie 的 SessionID 都存在这个问题。
尤其是 Cookie，虽然 Cookie 在服务器端下发时带上 HttpOnly ，JS 就无法读取到 Cookie，从而来避免 Cookie 中的 SessionID 泄露，造成安全问题，但是，别忘了 CSRF 问题，Cookie 也可能被利用，从而造成攻击。
如果只是为了避免 Cookie (SessionID)、Token 在传输层被截获，那你就应该考虑至少使用 HTTPS ，因为这样可以避免用户在与服务器交互时 Token、Cookie 被第三人截获的可能。
现在你可能会觉得既然客户端把 Token 存在 Cookie 不安全，那我是不是可以存在其他地方，比如 LocalStorage、SessionStorage 里面？
当然！你确实可以这样做，但是你可能忽略了另一个东西 XSS ，如果你的代码中产生了 XSS 漏洞，那么你无论存在客户端哪儿，都是一样的效果，照样可以被扒走。这时候你除了注意 XSS ，你可能还要注意一下 CSP(内容安全策略) 了，就是你加载的第三方资源安全吗？
最后来在说一下，你这个使用 UserId+Token+时间戳+密钥+请求参数 进行签名然后发送，这样靠谱吗？
不是靠谱，你移动端需要始终都需要那个重要的东西 密钥 ，而这里你要做的主要工作还是防止密钥被获取，因为一旦密钥丢失，别人就可以轻松利用，而且还会无端浪费服务器资源。
以前我也曾提出过这样的方案，并且被实施了，但是在后面的实践中发现，这样做的意义并不大。
你要做的，更多的时候只是需要最简单的，就是使用 HTTPS 。
关于 HTTPS 的知识，可以看下面这两个视频的介绍，可以更加直观的让你去了解
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
