token的组成
token串的生成流程。
token在客户端与服务器端的交互流程
Token的优点和思考
参考代码：核心代码使用参考，不是全部代码
JWT token的组成
头部（Header），格式如下：
{
“typ”: “JWT”,
“alg”: “HS256”
}
由上可知，该token使用HS256加密算法，将头部使用Base64编码可得到如下个格式的字符串：
eyJhbGciOiJIUzI1NiJ9- 1
有效载荷（Playload）：
{
“iss”: “Online JWT Builder”,
“iat”: 1416797419,
“exp”: 1448333419,
…….
“userid”:10001
}
有效载荷中存放了token的签发者（iss）、签发时间（iat）、过期时间（exp）等以及一些我们需要写进token中的信息。有效载荷也使用Base64编码得到如下格式的字符串：
eyJ1c2VyaWQiOjB9- 1
签名（Signature）：
将Header和Playload拼接生成一个字符串str=“eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyaWQiOjB9”，使用HS256算法和我们提供的密钥（secret,服务器自己提供的一个字符串）对str进行加密生成最终的JWT，即我们需要的令牌（token），形如：str.”签名字符串”。
token在服务与客户端的交互流程
1：客户端通过用户名和密码登录
2：服务器验证用户名和密码，若通过，生成token返回给客户端。
3：客户端收到token后以后每次请求的时候都带上这个token，相当于一个令牌，表示我有权限访问了
4：服务器接收（通常在拦截器中实现）到该token，然后验证该token的合法性（为什么能验证下面说）。若该token合法，则通过请求，若token不合法或者过期，返回请求失败。
关于Token的思考
服务如何判断这个token是否合法？
由上面token的生成可知，token中的签名是由Header和有效载荷通过Base64编码生成再通过加密算法HS256和密钥最终生成签名，这个签名位于JWT的尾部，在服务器端同样对返回过来的JWT的前部分再进行一次签名生成，然后比较这次生成的签名与请求的JWT中的签名是否一致，若一致说明token合法。由于生成签名的密钥是服务器才知道的，所以别人难以伪造。
token中能放敏感信息吗？
不能，因为有效载荷是经过Base64编码生成的，并不是加密。所以不能存放敏感信息。
Token的优点
（1）相比于session，它无需保存在服务器，不占用服务器内存开销。
（2）无状态、可拓展性强：比如有3台机器（A、B、C）组成服务器集群，若session存在机器A上，session只能保存在其中一台服务器，此时你便不能访问机器B、C，因为B、C上没有存放该Session，而使用token就能够验证用户请求合法性，并且我再加几台机器也没事，所以可拓展性好就是这个意思。
（3）由（2）知，这样做可就支持了跨域访问。