☕【权限设计系列】「认证授权专题」微服务中的JWT协议以及全方面概念介绍指南

JWT 介绍说明

JSON Web Token(JWT)是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准(RFC 7519)。

来自JWT RFC 7519标准化的摘要说明:JSON Web Token是一种紧凑的,URL 安全的方式,表示要在双方之间传输的声明。

JWT 用途形式

JWT一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该 Token 也可直接被用于认证,也可被加密。

JWT 认证流程

客户端处理方式
  1. 客户端不需要持有密钥,由服务端通过密钥生成Token。

  2. 客户端登录时通过账号和密码到服务端进行认证,认证通过后,服务端通过持有的密钥生成Token,Token中一般包含失效时长和用户唯一标识,如用户ID,服务端返回Token给客户端。

  3. 客户端保存服务端返回的Token。

  4. 客户端进行业务请求时在Head的Authorization字段里面放置Token,如: Authorization: Bearer Token

服务端处理方式
  1. 服务端对请求的Token进行校验,并通过Redis查找Token是否存在,主要是为了解决用户注销,但Token还在时效内的问题,如果Token在Redis中存在,则说明用户已注销;如果Token不存在,则校验通过。

  2. 服务端可以通过从Token取得的用户唯一标识进行相关权限的校验,并把此用户标识赋予到请求参数中,业务可通过此用户标识进行业务处理。

  3. 用户注销时,服务端需要把还在时效内的Token保存到Redis中,并设置正确的失效时长。

image

JWT 结构

JWT 是由三段信息构成的:

  • 第一段为头部(Header)
  • 第二段为载荷(Payload)
  • 第三段为签名(Signature)。

每部分内容都是一个JSON 对象,将每一段JSON对象采用BASE64编码,将编码后的内容用. 链接一起就构成了 JWT 字符串。如下:

header.payload.signature
头部(Header)

头部用于描述关于该 JWT 的最基本的信息,例如其类型以及签名所用的算法等。这也可以被表示成一个 JSON 对象。

{ "typ": "JWT", "alg": "HS256” }

在头部指明了签名算法是 HS256 算法。

载荷(payload)

载荷就是存放有效信息的地方。有效信息包含三个部分:

标准中注册的声明、公共的声明、私有的声明

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

    • iss:JWT 签发者
    • sub:JWT 所面向的用户
    • aud:接收 JWT 的一方
    • exp:JWT 的过期时间,这个过期时间必须要大于签发时间
    • nbf:定义在什么时间之前,该 JWT 都是不可用的
    • iat:JWT 的签发时间
    • jti:JWT 的唯一身份标识,主要用来作为一次性 token, 从而回避重放攻击。
  • 公共的声明 :公共的声明可以添加任何的信息,一般添加用户的相关信息或其他业务需要的必要信息. 但不建议添加敏感信息,因为该部分在客户端可解密。

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

示例如下:
{ "iss": "Online JWT Builder", "iat": 1416797419, "exp": 1448333419, "aud": "www.primeton.com", }
签名(signature)

创建签名需要使用 Base64 编码后的 header 和 payload 以及一个秘钥。将 base64 加密后的 header 和 base64 加密后的 payload 使用. 连接组成的字符串,通过 header 中声明的加密方式进行加盐 secret 组合加密,然后就构成了 jwt 的第三部分。

比如:HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

你可能感兴趣的:(☕【权限设计系列】「认证授权专题」微服务中的JWT协议以及全方面概念介绍指南)