JSON WEB TOKEN

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

1.基本概念

  1. Token和Session的区别

基于Session的认证

http协议是一种无状态协议,用户在登录时向服务端提供用户名和密码进行用户认证,下一次请求时,用户还要再一次进行用户认证才行,因为http协议是无状态的,服务器并不知道是哪个用户发出的请求。
为了让服务端能识别是哪个用户发出的请求,服务端需要在用户登录时存储一份用户登录的信息,该信息由Session值来标识,服务端生成Session后将SessionId作为登录的响应数据传递给浏览器,让浏览器保存为cookie,方便下次请求时发送给服务端,这样服务器就能识别是来自哪个用户的请求了。

Session认证暴露的问题
  1. 资源开销:每个用户进行登录认证,服务端应用做一次记录,方便用户下次请求的鉴别,为了能够快速响应用户请求,通常需要把session保存在内存中,而随着认证用户的增加,服务端的开销会明显增大。
  2. 扩展性:用户登录认证记录被保存在当前服务端中,意味着用户下次请求还必须要在这台服务器上才能拿到授权的资源。随着用户并发的增大,web应用如果要扩展成分布式应用,采用session的认证将会变得很难扩展,虽然可以用redis来做分布式session共享,但是还是占用了相当大的内存开销。
  3. CSRF:因为是基于cookie来进行用户识别的,如果cookie被截获,就会很容易受到跨站请求伪造的攻击。

基于Token的认证

基于token的认证不需要在服务端保存用户的认证信息或者会话信息,该认证机制的应用不需要考虑用户在哪一台服务器登录,为应用的扩展提供了便利。

鉴权流程

  1. 客户端使用用户名和密码进行登录请求
  2. 服务端接收用户的登录请求,进行用户信息的认证
  3. 服务端为认证通过的用户生成token,在登录请求的响应体里返回给客户端
  4. 客户端存储登录时的token,并在每次请求服务端时附带上存储的token
  5. 服务端验证token值并返回数据。

这个token必须要在每次请求时传递给服务端,它应该保存在请求头里, 另外,服务端要支持CORS(跨来源资源共享)策略,一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *。

2. 基础知识

JWT长什么样?
以下是一段JWT字符串示例

1
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImxhbnNoaXFpbiIsImFkbWluIjp0cnVlfQ.QzO3RdsVgG4MxikyFDXt55jIjnjAPF49vvPL_fUd_KQ

JWT的结构

JWT由以下三个部分组成

  • HEADER:(头部,生成算法和token类型,算法一般是,token类型这里是jwt)
  • PAYLOAD: (有效载荷, 这里存放一些要传输的数据)
  • VERIFY SIGNATURE (签名验证)

三个部分用符号 . 连接起来,构成了JWT字符串,格式如下所示

1
xxxxx.yyyyy.zzzzz

jwt的头部承载两部分信息:

  • 声明类型,这里是jwt
  • 声明加密的算法 通常直接使用 HMAC SHA256
    完整的头部就像下面这样的JSON:
    1
    2
    3
    4
    {
    "alg": "HS256",
    "typ": "JWT"
    }

然后将头部进行base64加密(该加密是可以对称解密的),构成了第一部分.

1
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

playload

载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品,这些有效信息包含三个部分

  • 标准中注册的声明
  • 公共的声明
  • 私有的声明
    标准中注册的声明 (建议但不强制使用) :

  • iss: jwt签发者

  • sub: jwt所面向的用户
  • aud: 接收jwt的一方
  • exp: jwt的过期时间,这个过期时间必须要大于签发时间
  • nbf: 定义在什么时间之前,该jwt都是不可用的.
  • iat: jwt的签发时间
  • jti: jwt的唯一身份标识,主要用来作为一次性token,从而回避重放攻击。
公共的声明 :

公共的声明可以添加任何的信息,一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息,因为该部分在客户端可解密.

私有的声明 :

私有声明是提供者和消费者所共同定义的声明,一般不建议存放敏感信息,因为base64是对称解密的,意味着该部分信息可以归类为明文信息。

定义一个payload:

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

然后将其进行base64加密,得到Jwt的第二部分。

1
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImxhbnNoaXFpbiIsImFkbWluIjp0cnVlfQ

signature

jwt的第三部分是一个签证信息,这个签证信息由三部分组成:

  • header (base64后的)
  • payload (base64后的)
  • secret
    这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串,然后通过header中声明的加密方式进行加盐secret组合加密,然后就构成了jwt的第三部分。
    最终的JWT:
    1
    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImxhbnNoaXFpbiIsImFkbWluIjp0cnVlfQ.QzO3RdsVgG4MxikyFDXt55jIjnjAPF49vvPL_fUd_KQ

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

如何应用

一般是在请求头里加入Authorization,并加上Bearer标注:

1
2
3
headers: {
'Authorization': 'Bearer ' + token
}

服务端会验证token,如果验证通过就会返回相应的资源。整个流程如下图所示:

总结

优点

  • 因为json的通用性,所以JWT是可以进行跨语言支持的,像JAVA,JavaScript,NodeJS,PHP等很多语言都可以使用。
  • 因为有了payload部分,所以JWT可以在自身存储一些其他业务逻辑所必要的非敏感信息。
  • 便于传输,jwt的构成非常简单,字节占用很小,所以它是非常便于传输的。
  • 它不需要在服务端保存会话信息, 所以它易于应用的扩展

安全相关

  • 不应该在jwt的payload部分存放敏感信息,因为该部分是客户端可解密的部分。
  • 保护好secret私钥,该私钥非常重要。
  • 如果可以,请使用https协议
0%