JWT笔记

JWT ：将用户登录状态以及数据用加密的json格式存储在客户端，服务端就可以依靠这个字符串认定用户身份。

JWT实际上就是一个字符串 由三部分组成：header（头部）、payload（载荷）、signature（签名）

Header：承接两部分信息，然后对头部进行base64编码，构成第一部分

{

"typ": "JWT",  //声明类型就是jwt

"alg": "HS256"  //声明加密算法 一般是HMAC SHA256（HS256）

}

Payload：存放有效信息，自定义的数据用户ID等，因为这些数据就是使后端知道此token是哪个用户已经登录的凭证。而且这些数据是存在token里面的，由前端携带，所以后端几乎不需要保存任何数据。然后将其进行base64编码，得到Jwt的第二部分。

大致分为：注册声明（比如 iss ：JWT签发者 sub： JWT面向的用户 aud ：接受jwt的一方  exp：过期时间  iat：签发时间 jti：jwt唯一身份标识，主要用来生成一次性的token ）公共声明，私有声明

{

   'id': user.id,

   'username': user.username，

   ‘exp’: time.time() + 300,  #过期时间

}

Signature：使用编码后的header和payload以及一个秘钥，使用声明的编码方式进行组合加密。加密的秘钥存在后端服务器中。

最后将 token = header + '.'+ payload +'.'+ signature,生成token。

Token登录的原理

首先 用户输入账号和密码进行登录，后端根据数据库验证用户，验证通过 生成token

然后 前端将后端返回的token保存起来（比如放到cookie中） 每次用户访问请求都带着token（可以在cookie或者header中携带） 在后端经过拦截器的拦截 如何再进行判断 如果token验证通过 放行 不通过 则不能让用户访问界面

在实际中如何应用

设置token的生成代码

从token中获取有用信息

验证token

JWT认证的流程

（1）首先，前端通过Web表单将自己的用户名和密码发送到后端的接口，这个过程一般是一个POST请求。建议的方式是通过SSL加密的传输(HTTPS)，从而避免敏感信息被嗅探

（2）后端核对用户名和密码成功后，将包含用户信息的数据作为JWT的Payload，将其与JWT Header分别进行Base64编码拼接后签名，形成一个JWT Token，形成的JWT Token就是一个如同lll.zzz.xxx的字符串

（3）后端将JWT Token字符串作为登录成功的结果返回给前端。前端可以将返回的结果保存在浏览器中，退出登录时删除保存的JWT Token即可

（4）前端在每次请求时将JWT Token放入HTTP请求头中的Authorization属性中(解决XSS和XSRF问题)

（5）后端检查前端传过来的JWT Token，验证其有效性，比如检查签名是否正确、是否过期、token的接收方是否是自己等等

（6）验证通过后，后端解析出JWT Token中包含的用户信息，进行其他逻辑操作(一般是根据用户信息得到权限等)，返回结果

为什么用JWT而不用session？

传统session认证存在弊端。http协议本身是一种无状态协议，这就意味着如果用户向我们的应用提供了用户名的密码来进行用户认证，认证通过后http协议并不会记录下认证后的状态，那么下一次请求时，还要再进行一次认证。为了能够让我们的应用能识别出是哪个用户发出的请求，只能在用户首次登录成功后，在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie，以便下次请求时发送给我们的应用，）这样应用就能识别出请求来自哪个用户。

存在的问题

1. 每个用户的登录信息都会保存在服务器的session中，随着用户的增多，加大服务器开销
2. 由于session是存在于服务器的物理内存中，所以在分布式系统中，这种方式会失效。虽然可以将session统一保存到Redis中，但这样做增加了系统的复杂性，对于不需要Redis的应用也会白白引入一个缓存中间件。
3. 对于非浏览器的客户端、手机移动端等都不适用，因为session依赖于cookie，而移动端经常没有cookie
4. 因为session认证本质基于cookie，所以如果cookie被截获，用户很容易收到跨站请求伪造攻击。并且如果浏览器禁用了cookie，这种方式也会失效
5. 前后端分离系统中更加不适用，后端部署复杂，前端发送的请求往往经过多个中间件到达后端，cookie中关于session的信息会转发多次
6. 由于基于Cookie，而cookie无法跨域，所以session的认证也无法跨域，对单点登录不适用。

相比于传统的session认证方式，JWT优势是：

1. JWT token数据量小，传输速度也很快
2. Token是以json加密形式保存在客户端的，所以jwt是跨语言的，原则上任何web形式都支持。
3. 不需要在服务端保存会话信息，也就是不依赖于cookie和session，所以没有传统session认证的弊端，特别适用于分布式微服务。
4. 单点登录友好：使用token进行认证的话， token可以被保存在客户端的任意位置的内存中，不一定是cookie，所以不依赖cookie，不会存在这些问题。
5. 适合移动端应用。

使用MD5加盐进行加密并采用JWT进行验证

MD5：信息-摘要算法  本质是一种散列函数，使用的是hash算法

MD5性质：（1）压缩性：输出都是128位（16字节） （2）容易计算  （3）抗修改性：原数据一旦修改，MD5值都会有很大区别  （4）抗碰撞性：已知原数据和其MD5值，想找到一个具有相同MD5值的数据（即伪造数据）十分困难 （5）不可逆特性：单向密码体制，从明文到密文的不可逆映射，只有加密过程没有解密过程

为什么不可逆？

因为MD5无论输入多少字节的数据，最后输出都是16位，所以它的运算过程存在信息丢失的，由于不确定运算过程中会在哪一步被丢弃，因此仅仅根据MD5的计算过程和得到的最终结果，是无法逆向计算出明文的

MD5加盐

MD5+salt原理

MD5算法在保存用户密码信息的过程中，加入盐。盐可以是生成的随机数，也可以是自定义的数据。将密码结合MD5加盐，生成的数据摘要和盐保存起来 。以便于下次用户验证使用。就是在用户表里面，也保存salt。

为什么要MD5加盐？

我们知道如果直接对密码进行散列，那么黑客可以对通过获得这个密码散列值，然后通过查散列值字典（如MD5密码破解网站），得到某用户的密码。

加Salt可以一定程度上解决这一问题。所谓加Salt方法，就是加点“佐料”。其基本想法是这样的：当用户首次提供密码时（通常是注册时），由系统自动往这个密码里撒一些“佐料”，然后再散列。而当用户登录时，系统为用户提供的代码撒上同样的“佐料”，然后散列，再比较散列值，以确定密码是否正确。

这里的“佐料”被称作“Salt值”，这个值是如果由系统随机生成的，并且只有系统知道。这样，即便两个用户使用了同一个密码，由于系统为它们生成的salt值不同，他们的散列值也是不同的。破解的几率大大减小。

实现代码：

（给自己指路）  

http://t.csdnimg.cn/5uqXd