【译】JWT(JSON Web Token) 入门指南 (2)

签名是让服务器无状态处理用户HTTP请求的关键,他使得服务器只需要验证请求中携带的token即可,无需每次都携带用户名和密码。

JWTs的目的是无状态的服务吗

让服务无状态只是好的影响,JWTs的关键好处是认证服务器产生JWT和应用服务器验证JWT可以完全分离。

也就是说服务仅需要最小层度的认证逻辑即可--验证JWT。

这也让一个集群中的所有应用都可以把注册登录流程放在一个单独的认证服务器上。

这也使得应用服务器更加简单,也更加安全。因为大部分认证功能都在认证服务器,而且应用见可以共用。

现在我们清楚的知道了JWT是怎么让服务器无状态的,让我们来看看具体的实现细节吧!

JWT 是什么样子的

(这里有一个视频讲解JWT的三个组成部分)
接下来我们看看一个从网上验证工具<jwt.io>上的JWT的例子:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

你可能会想,Json对象哪里去了呢?不要急,我们接下来会讲。实际上在本篇末尾,你会深入了解这个奇怪字符串的方方面面。

我们可以看到这个字符串使用点号划分了3部分,第一个点号之前的就代表JWT头:

JWT Header: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

第二部分,两个点号之间的字符串是载体:

JWT Payload: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

第二个点号后的部分就是签名部分:

JWT Signature: TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

如果你想自己确认信息是否是对的,你可以从JWT验证工具网站上复制过来,来比较一下。

那么,这些字符到底是什么呢?我们怎么从JWT上获取可读的信息用来排查问题呢?<jwt.io>是怎么得到原json对象的呢?

被包装的Base64,是不是就是Base64Url?

事实上,载体、头和签名都还是可读的格式。

我们只是想要确保在网络上传输的JWTtoken不会由于编码问题变成乱码(如“garbled text” qîüö:Ã)。

乱码问题是由于世界上的计算机没有统一的处理字符串编码的方式,比如 UTF-8、ISO8859-1等。

这个乱码问题很普遍:无论什么时候我们从平台上获取一个字符串,都是用了一个编码的方式。及时我们没有指定编码方式:

要么是操作系统默认的编码方式

要么是服务端默认的配置参数

我们希望通过网络传输的字符不必考虑这些问题,这就要求我们选择的字符集被所有的编码方式处理都有统一的结果,这就是为什么Base64编码格式的要解决的问题。

Base64 vs Base64Url

但是我们上面看到的JWT并不是Base64编码的,而是Base64Url。

它和Base64只是有几个字符不一样,所以我们可以把JWT当成是url参数进行传输,这也就是一些第三方登录页面重定向到我们的网站的方式。

让我们看看上面提到的JWT载体:

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

我们可以从这个网站上解码:

{"sub":"1234567890","name":"John Doe","admin":true}

我们就得到了Json载体!这就为我们排查问题提供了信息。我们确实使用Base64解码器,接下来会更加深入了解这个编码,现在我们总结一下:

总结:我们知道了JWT 头和载体的内容形式:他们就是两个JavaScript对象,然后被转化成json格式,最后被以Base64Url编码,并以点号分隔。

这种格式就是发送json数据的实用方式。

下面这个视频展示了一些代码--展示了怎么生成、验证JWT token,并且详细展示了头和载体部分:

在我们讲签名之前,我们看看我们认证的时候在载体中放了些什么。

JWTs用户会话管理:主体和过期

我们之前提到过,JWT 载体可以是任何信息,而不仅仅是身份信息。通常我们在使用JWT 做验证的时候,我们会放几个信息:

用户的身份信息

会话过期时间

下面是我们常用放入载体的信息:

{ "iss": "Identifier of our Authentication Server", "iat": 1504699136, "sub": "github|353454354354353453", "exp": 1504699256 }

解释一下这些属性:

iss 代表认证实体,这里是我们的认证服务器

iat JWT创建时间(以秒为单位)

sub 用户的唯一标识

exp token 过期时间

这就是被称为 Bearer Token(携带信息的token),它表明了:

认证服务器确认了携带这个token的用户是sub属性指定的对应用户,放行吧

在我们知道了JWT 载体的典型用户之后,我们来看看签名吧。

JWTs 中有各种签名,本文会探讨其中的两种:HS256 和 RS256。我们从HS256 开始吧。

HS256 数字签名 - 他是如何工作的

像大多数签名一样,HS256数字签名是基于特定类型的算法:加密哈希算法。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zwfsys.html