什么是jwt?

JSON Web Tokens

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

更多见 https://jwt.io/

为什么用jwt?

无状态

http://www.ruanyifeng.com/blog/2011/09/restful

JWT的主要应用场景

  • 身份认证在这种场景下，一旦用户完成了登陆，在接下来的每个请求中包含JWT，可以用来验证用户身份以及对路由，服务和资源的访问权限进行验证。由于它的开销非常小，可以轻松的在不同域名的系统中传递，所有目前在单点登录（SSO）中比较广泛的使用了该技术。
  • 信息交换在通信的双方之间使用JWT对数据进行编码是一种非常安全的方式，由于它的信息是经过签名的，可以确保发送者发送的信息是没有经过伪造的。

JWT的结构

JWT包含了使用.分隔的三部分：

  • Header 头部
  • Payload 负载
  • Signature 签名
1
xxxxx.yyyyy.zzzzz
  • Header
    在header中通常包含了两部分：token类型和采用的加密算法。
    1
    2
    3
    4
    {
      "alg": "HS256",
      "typ": "JWT"
    }

接下来对这部分内容使用 Base64Url 编码组成了JWT结构的第一部分。

  • Payload
    Token的第二部分是负载，它包含了claim， Claim是一些实体（通常指的用户）的状态和额外的元数据，有三种类型的claim： reserved, public 和 private.

Reserved claims: 这些claim是JWT预先定义的，在JWT中并不会强制使用它们，而是推荐使用，常用的有 iss（签发者）, exp（过期时间戳）, sub（面向的用户）, aud（接收方）, iat（签发时间）。
Public claims：根据需要定义自己的字段，注意应该避免冲突
Private claims：这些是自定义的字段，可以用来在双方之间交换信息
负载使用的例子：

1
2
3
4
5
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

上述的负载需要经过Base64Url编码后作为JWT结构的第二部分。

Signature

创建签名需要使用编码后的header和payload以及一个秘钥，使用header中指定签名算法进行签名。例如如果希望使用HMAC SHA256算法，那么签名应该使用下列方式创建：

1
2
3
4
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

签名用于验证消息的发送者以及消息是没有经过篡改的。

JWT Token需要持久化在缓存中吗?

不需要,这样背离了JWT通过算法验证的初心

在退出登录时怎样实现JWT Token失效呢？

退出登录,只要客户端端把Token丢弃就可以了,服务器端不需要废弃Token.

怎样保持客户端长时间保持登录状态?

服务器端提供刷新Token的接口, 客户端负责按一定的逻辑刷新服务器Token.

服务器端是否应该从JWT中取出userid用于业务查询?

RESTful是无状态的,意味着服务器端每次请求都是独立的,即不依赖以前请求的结果,因此也不应该依赖JWT token做业务查询,应该在请求报文中单独加个userid字段.
为了做用户水平越权的检查,可以在业务层判断传入的userid和从JWT token中解析出的userid是否一致,有些业务可能会允许查不同用户的数据.

签名的目的是什么？

最后一步签名的过程，实际上是对头部以及载荷内容进行签名。一般而言，加密算法对于不同的输入产生的输出总是不一样的。对于两个不同的输入，产生同样的输出的概率极其地小（有可能比我成世界首富的概率还小）。所以，我们就把“不一样的输入产生不一样的输出”当做必然事件来看待吧。

所以，如果有人对头部以及载荷的内容解码之后进行修改，再进行编码的话，那么新的头部和载荷的签名和之前的签名就将是不一样的。而且，如果不知道服务器加密的时候用的密钥的话，得出来的签名也一定会是不一样的。

服务器应用在接受到JWT后，会首先对头部和载荷的内容用同一算法再次签名。那么服务器应用是怎么知道我们用的是哪一种算法呢？别忘了，我们在JWT的头部中已经用alg字段指明了我们的加密算法了。

如果服务器应用对头部和载荷再次以同样方法签名之后发现，自己计算出来的签名和接受到的签名不一样，那么就说明这个Token的内容被别人动过的，我们应该拒绝这个Token，返回一个HTTP 401 Unauthorized响应。

Base64是一种编码,是可逆的,那么我的信息不就被暴露了吗？

是,所以，在JWT中，不应该在载荷里面加入任何敏感的数据。在上面的例子中，我们传输的是用户的User ID。这个值实际上不是什么敏感内容，一般情况下被知道也是安全的。
但是像密码这样的内容就不能被放在JWT中了。如果将用户的密码放在了JWT中，那么怀有恶意的第三方通过Base64解码就能很快地知道你的密码了。

jwt 生成通过一个secret生成token

secret是保存在服务器端的,jwt的签发生成也是在服务器端的,secret就是用来进行jwt的签发和jwt的验证,所以,它就是你服务端的私钥，,任何场景都不应该流露出去.一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了.

如何使用JWT？

在身份鉴定的实现中，传统方法是在服务端存储一个session，给客户端返回一个cookie，而使用JWT之后，当用户使用它的认证信息登陆系统之后，会返回给用户一个JWT，用户只需要本地保存该token（通常使用local storage，也可以使用cookie）即可。

当用户希望访问一个受保护的路由或者资源的时候，通常应该在Authorization头部使用Bearer模式添加JWT，其内容看起来是下面这样：

1
Authorization: Bearer <token>

因为用户的状态在服务端的内存中是不存储的，所以这是一种无状态的认证机制。服务端的保护路由将会检查请求头Authorization中的JWT信息，如果合法，则允许用户的行为。由于JWT是自包含的，因此减少了需要查询数据库的需要。

  • 我自己主导的项目是,如果是前台项目那么只进行token校验,而不进行数据库查询;但是后台项目的话,在第一次授权后会把用户信息存到redis中,之后权限拦截是根据token去redis中获取,然后得到权限数据进行权限处理,毕竟权限信息很多,而且查询出来后还需要递归组织好关系,所以直接第一次组织好后存redis,之后就直接获取就行了

JWT的这些特性使得我们可以完全依赖其无状态的特性提供数据API服务，甚至是创建一个下载流服务。因为JWT并不使用Cookie的，所以你可以使用任何域名提供你的API服务而不需要担心跨域资源共享问题（CORS）。

为什么要使用JWT？

相比XML格式，JSON更加简洁，编码之后更小，这使得JWT比SAML更加简洁，更加适合在HTML和HTTP环境中传递。

在安全性方面，SWT只能够使用HMAC算法和共享的对称秘钥进行签名，而JWT和SAML token则可以使用X.509认证的公私秘钥对进行签名。与简单的JSON相比，XML和XML数字签名会引入复杂的安全漏洞。

因为JSON可以直接映射为对象，在大多数编程语言中都提供了JSON解析器，而XML则没有这么自然的文档-对象映射关系，这就使得使用JWT比SAML更方便。

jwt流程

  • 验证用户密码
  • 授权
  • 发放token
  • 客户端每次请求携带token
  • 验证token
  • 返回请求数据

代码示例

摘自

.