本文共 3269 字，大约阅读时间需要 10 分钟。
什么是JSON Web Token
JWT 是 Json Web Tokens 的缩写，与传统 Web 的 Cookies 或者 Session 方式的认证不同的是，JWT 是无状态的，服务器上不需要对 token 进行存储，也不需要和客户端保持连接。而 JWT 的 token 分3个部分，首先是头部 ，表明这是一个JWT，并指明加密方式，第二部分是负载，其中可以包含 账户名、ID、邮箱等用户信息，同时也包含了token到期时间，以 Unix 时间戳的方式记录，头部和负载都会进行 base64 编码，最后一部分是签名，用来验证负载的信息是否正确。
服务器上会保存一个全局 JWT_SECRET ，用于生成 token 和验证 token。在用户登录成功后，服务器从数据库获取用户的相关信息，计算出 token 到期时间，生成头部和负载并编码，再将前面的内容使用 JWT_SECRET 进行加密，生成签名，最后将3个部分合并返回给客户端。
客户端访问需要认证的客户端时，在 Http 请求头部加上 Authrization 字段，内容为 Bearer 加 token。服务器收到请求后，利用 JWT_SECRET 验证 token 是否合法，从负载中提取到期时间确认 token 是否过期，再从 token 提取用户信息，与数据库进行对比。如果这些都通过的话就可以进行后续操作了。
什么时候应该使用JSON Web Token？
下面是一些JSON Web令牌有用的场景：
授权：这是使用JWT的最常见场景。一旦用户登录，每个后续的请求都将包括JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是目前广泛使用JWT的一个特性，因为它的开销很小，而且可以很容易地在不同的项目领域中使用。 信息交换：JSON Web令牌是在各方之间安全地传输信息的一种很好的方式。因为JWTs可以被签署——例如，使用公钥/私钥对——您可以确定发送者是他们所说的他们。此外，由于签名是使用头和有效负载计算的，所以您还可以验证内容没有被篡改。JSON Web Token的组成
JSON Web令牌由由点(.)分隔的三个部分组成：
1 Header
2 Payload 3 Signature因此，JWT通常看起来是这样的。
xxxxx.yyyyy.zzzzz 让我们分解不同的部分。Header
头信息通常包含两部分，type：代表token的类型，这里使用的是JWT类型。 alg:使用的Hash算法，例如HMAC SHA256或RSA. 例如: { :“alg HS256”, :“typ JWT” } 然后，这个JSON是Base64Url编码，以形成JWT的第一部分。 Payload 第二个部分是荷载信息，它包含一些声明Claim(实体的描述，通常是一个User信息，还包括一些其他的元数据) signature jwt的第三部分是一个签证信息，这个签证信息由三部分组成： header (base64后的) payload (base64后的) secret 这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。JWT登录状态信息续签问题
比如设置token的有效期为一个小时，那么一个小时后，如果用户仍然在这个web应用上，这个时候当然不能指望用户再登录一次。目前可用的解决办法是在每次用户发出请求都返回一个新的token，前端再用这个新的token来替代旧的，这样每一次请求都会刷新token的有效期。但是这样，需要频繁的生成token。另外一种方案是判断还有多久这个token会过期，在token快要过期时，返回一个新的token。服务器在头部返回一个新的Authorization字段，客户端提取相应头信息
JWT用户主动注销
JWT并不支持用户主动退出登录，当然，可以在客户端删除这个token，但在别处使用的token仍然可以正常访问。为了支持注销，我的解决方案是在注销时将该token加入黑名单。当用户发出请求后，如果该token在黑名单中，则阻止用户的后续操作，返回Invalid token错误。这个地方我再稍微补充一下，其实这里的黑名单操作也比较简单，把已经注销的token存入比如说一个set中，那么在每次进行token验证时，先检查在set中是否已经存在，如果已经存在的话，则视为token已经失效，直接返回未授权。这一部分在上面的授权代码中也可以看到，不过我是放到redis缓存中的。
JWT Cookie存储的安全性
Cookies，当使用带有HttpOnly的cookie标志时，通过JavaScript是无法访问的，并且对XSS是免疫的。你还可以设置安全的cookie标志来保证cokie仅通过HTTPS发送。这是过去利用cookie存储令牌或会话数据的主要原因之一。现代开发人员不愿使用cookie,因为它们通常要求状态被存储在服务器上,从而打破RESTful的最佳实践。如果你在cookie上存储JWT，cookie作为存储机制不用将状态存储在服务器上。这是因为JWT封装了所有服务器需要服务的请求。
然而，cookies容易受到不同类型的攻击：跨站点请求伪造(CSRF)。CSRF攻击是当一个恶意网站，电子邮件或博客导致用户在当前已验证用户的可信站点上的web浏览器中，执行一个有害的动作时发生的攻击。这是一个浏览器如何处理cookies的漏洞。cookie只能被发送到的允许的域中。默认情况下，这个是最初设置cookie的域。。 。，并试图劫持你的会话，如果它仍然有效，就修改您的帐户。 例如：，并可能导致未经授权的状态改变。使用同步令牌模式，CSRF是可以预防的。这听起来很复杂，但是所有现代的web框架都支持这个。
例如，AngularJS有一个解决方案去验证，只能由你的域才能访问cookie。直接来自AngularJS文档: 当执行XHR请求时，$http服务从cookie中读取令牌(默认，XSRF-TOKEN)并将其作为一个http头(X-XSRF-TOKEN)。因为只有JavaScript运行在你的域才可以读取cookie,你的服务器可以确信XHR来 自你的域中运行的JavaScript。通过包含一个xsrfToken JWT claim，你可以让这个CSRF保护无状态。{ "iss": "http://galaxies.com", "exp": 1300819380, "scopes": ["explorer", "solar-harvester", "seller"], "sub": "tom@andromeda.com", "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"} 如果我使用Stormpath SDK for AngularJS，获得无状态CSRF保护没有开发工作。
利用你的web应用程序框架的CSRF保护，使得cookies存储JWT绝对可靠。CSRF也可以从你的API中通过检查HTTP Referer和原始header部分阻止。CSRF攻击将有与应用程序无关的Referer和原始heade。 虽然他们更安全的存储你的JWT，cookies可能导致一些开发商头痛，这取决于你的应用程序的运转是否需要跨域访问。只是知道cookies有附加属性(域名/路径)，可以对其进行修改，从而允许你指定cookie的发送位置。使用AJAX，你的服务器端也可以通知浏览器证书(包含Cookies)是否应该随着CORS请求发送。转载地址：http://rtvxi.baihongyu.com/