关于 APP 后端使用 Token 机制进行认证的几点疑惑

Question

最近在做一个 APP 的后端，打算采用 Token 的认证机制。因为以前没做过，所以查阅了相关资料，了解到有一个 JSON Web Token 规范。感觉 JWT 比 md(userid+timestamp+salt) 这样的方式要方便很多啊，服务端可以不缓存 token，由客户端缓存，在处理请求时检查签名就可以了。但是感觉使用 JWT 的 APP 后端相关资料不多，更多的是 oAuth 协议。

主要的几点疑惑：

1. 使用 JWT 作为认证机制，服务端是不是就不需要缓存 JWT了？会不会存在问题呢？
2. JWT 的适用范围一般是 Web 项目吗？我 Google 时感觉没有多少谈论 APP 中的使用。
3. 目前 APP 后端关于用户权限这块，标准或者说比较成熟的解决方案是什么呢？能否介绍下或贴出一些资料？

非常感谢大牛答疑解惑。

Answer 1

服务端是不需要缓存全部jwt，但是需要缓存黑名单jwt： 一是是为了能让jwt立即失效，否则，只能等jwt自身过期。（适用于后台想禁用某个用户的情况） 二是为了新旧token刷新时有缓冲。 而楼上说的而token最好由服务端保存,只是一种方法而已，和jwt这种偏向客户端存储的各有优缺点，无好坏之说。

Answer 2

你说的那个不是严格意义上的token，而更像是签名中的相对随机数而token最好由服务端保存，而且最好在一定时间段里，token是固定的 先说一下为什么要加token？为什么要加签名？其实不加也是可以的，但为什么要加呢，加的作用是什么呢？当然你要是用oAuth就不在本文讨论了 加签名的最大的意义是防止参数被篡改后再访问，当然也有保证参数完整性的功能，但核心最重要的就是防止参数被篡改后再访问 而token是令牌，至少可以这么理解，它是你访问服务器接口的令牌，验证你的令牌和服务器当时给你分配的令牌是否一致，如果一致则进行下一步，否则就给打回去。 其实说接口权限规范，是仁者见仁智者见智，各种方式，各种结构，各有优缺点，但都有满足这最基本的需求就是：1、防止用户篡改请求参数2、不允许用户的请求被盗取而连续多发3、相对保证用户来源正确