OAuth2.0实战(三)-使用JWT(上)

授权服务的核心就是颁发访问令牌,而OAuth 2.0规范并没有约束访问令牌内容的生成规则,只要符合唯一性、不连续性、不可猜性。可以灵活选择令牌的形式,既可以是没有内部结构且不包含任何信息含义的随机字符串,也可以是具有内部结构且包含有信息含义的字符串。


之前生成令牌的方式都是默认一个随机字符串。而在结构化令牌这方面,目前用得最多的就是JWT令牌。

1 简介

JSON Web Token(JWT)是一个开放标准(RFC 7519),它定义了一种紧凑、自包含的方式,作为JSON对象在各方之间安全地传输信息,是用一种结构化封装的方式来生成token的技术。

结构化后的token可被赋予丰富含义,这是与无意义的随机字符串形式token的最大区别。

2 JWT结构

JWT这种结构化体可分为

HEADER(头部)

装载令牌类型和算法等信息,是JWT的头部。

  • typ 表示第二部分PAYLOAD是JWT类型
  • alg 表示使用HS256对称签名的算法

PAYLOAD(数据体)

JWT的数据体,代表了一组数据。

  • sub
    令牌的主体,一般设为资源拥有者的唯一标识)
  • exp
    令牌的过期时间戳
  • iat
    令牌颁发的时间戳

是JWT规范性的声明,PAYLOAD表示的一组数据允许我们自定义声明。

SIGNATURE(签名)

签名后的JWT整体结构,是被.分割的三段内容:header.payload.signature。JWT令牌直接用肉眼,看起来还是毫无意义,但如果拷贝到 https://jwt.io/ 在线校验,即可看到解码后的有意义数据。


SIGNATURE表示对JWT信息的签名。

作用

可能你觉得,有了HEADERPAYLOAD就可让令牌携带信息在网络中传输了,但在网络中传输这样的信息体不安全。必须加密签名,而SIGNATURE就是对信息的签名结果,当受保护资源接收到三方软件的签名后需要验证令牌的签名是否合法。

3 令牌内检

定义

既然授权服务颁发令牌,受保护资源服务就要验证令牌。而受保护资源调用授权服务提供的检验令牌的服务的这种校验令牌方式就叫令牌内检。

特点

有时授权服务依赖DB,然后受保护资源服务也依赖该DB,即“共享DB”。微服务架构下,不同系统间依靠服务而非DB通信,比如授权服务给受保护资源服务提供一个RPC服务:

OAuth2.0实战(三)-使用JWT(上)

JWT令牌本身包含了之前所要依赖DB或依赖RPC服务才能拿到的信息,比如某用户为某软件进行授权等信息。

4 JWT令牌怎么用?

  • 有JWT令牌后的通信方式
  • OAuth2.0实战(三)-使用JWT(上)
  • 授权服务发个令牌,受保护资源服务接这令牌,然后开始解析令牌所含信息,无需再去查询DB或RPC调用。即实现了令牌内检。

HMAC 流程

OAuth2.0实战(三)-使用JWT(上)

RSA 流程

OAuth2.0实战(三)-使用JWT(上)

上一篇:一条简单的sql语句运行15天的原因分析


下一篇:Mac or Centos 下如何编译objective-C