如何基于JWT实现用户身份认证

一、使用场景用于账号/密码登录

解决方案：

1.基于session认证

1）基于session认证方案

服务端生成httpsession（内存-sessionId）---->sessionId写到浏览器cookie--->浏览器请求的header中自动带sessionId到服务器---->服务端校验sessionId是否合法

2）优缺点

优点：实现简单

缺点：服务端压力大，用户的信息保存在服务器内存，用户量越大，内存开销越大。

扩展性差，用户信息存在某一服务器上，应用节点就会有状态，分布式下不能够水平无线扩延。

在java中可以用 spring-session-data-redis来解决这个问题，来在分布式节点下实现session共享。

普通的session认证不支持跨域。因为session需要配合cookie才能实现，由于cookie默认不支持跨域访问，所以，当涉及到前端跨域请求后端接口的时候，需要做很多额外的配置，才能实现跨域session认证。容易被类似的CSRF攻击。因为是基于浏览器的cookie来进行用户识别的，cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。适用场景:单节点部署应用，如果多节点部署情况下使用session共享/负载均衡端会话保持(SLB设置)

2.基于JWT校验方案

1)什么是JWT?JWT(JS0N Web Token)是目前最流行的跨域认证解决方案，是一种基于Token的认证授权机制。JWT自身包含了身份验证所需要的所有信息,因此，我们的服务器不需要存储Session信息。这显然增加了系统的可用性和伸缩性，大大减轻了服务端的压力。

2)JWT格式及组成
jwt也就是令牌的token，是一个String字符串，由三部分组成，中间用点隔开，连接在一起就一个JWT token，就像这样:EyJhbGCiOIJIUZI1NiISInR5CCI6IKDXVCJ9.VJZdWIiOIXMIMNTY30DKWIWI6MFtZSI6IKOVaG49RG9LIWIYWRtaWGI0nRVdWV9,TIVA950mM7E2cBab3@RMHPHCEfx
jwt token令牌组成:
标头(Header)
有效载荷(Payload)
签名(Signature)
token格式:head.payload.Signature 如:xxxxx.yyy.zz

详细解释如下所示:
Header:描述JWT的元数据，定义了生成签名的算法以及ToKen的类型。如HMAC、SHA256、RSA;使用Base64编码，如下
"alg":"HS256
"type” :"JWT"
以上经过base64后值:eyIhbGci0iJIUzI1NiISInR5CCI6IKpXVCJ9Payload:有效负载，用来存放实际需要传递的数据，千万不要放用户敏感的信息，如密码。同样使用Base64编码，如下:
sub”:"123”
"name" :"John Do",
admin" : true
以上经过base64后值:eyJzdWIi0iIxMJM0NTY30DkwIiwibmFtZSI6IkpvaG4gRG9LIiWiYWRtaW4i0nRydWV9Signature :前面两部分都使用Base64进行编码，前端可以解开知道里面的信息。Signature需要使用编码后的header和payload加上我们提供的一个密钥，使用header中指定的签名算法(HS256)进行签名。签名的作用是保证JWT没有被篡改过。HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret);处理完后值:TJVA950rM7E2cBab30RMHrHDcEfxjoYZgeF0NFh7HgQ注意:这里的secret私钥保存在服务端，非常的重要千万不能泄露，建议私钥做成可配置的，定期修改

3)优缺点
优点:
跨平台实现，token是加密的形式保存在客户端，与语言无关，原则上任何web形式都支持。
不需要存储Session，服务端节点可水平无限扩展。
不依赖Cookie,使得其可以防止CSRF攻击。
性能好，只需要在header中携带token，即可实现认证，传递数据少。
缺点:jwt生成的token在有效期内-直可用，因为主要存在客户端，无法在服务端删除。用户登出，只能在客户端localStorage删除token，无法在服务端控制。jwt本身无法实现用户禁止登录或拉黑用户，都需要业务自己实现。适用场录:分布式集群