学学JWS,JWT

前言

上一篇文章我们已经看了iOS StoreKit 2 今天我们来看看 他们的加密算法JWS

聊聊JWT和OAuth2

要比较JWT和OAuth2，首先要明白一点就是，这两个根本没有可比性，是两个完全不同的东西。

JWT是一种认证协议

JWT提供了一种用于发布接入令牌（Access Token),并对发布的签名接入令牌进行验证的方法。 令牌（Token）本身包含了一系列声明，应用程序可以根据这些声明限制用户对资源的访问。

OAuth2是一种授权框架

另一方面，OAuth2是一种授权框架，提供了一套详细的授权机制（指导）。用户或应用可以通过公开的或私有的设置，授权第三方应用访问特定资源。

为什么要比较

既然JWT和OAuth2没有可比性，为什么还要把这两个放在一起说呢？实际中确实会有很多人拿JWT和OAuth2作比较。很多情况下，在讨论OAuth2的实现时，​

​会把JSON Web Token作为一种认证机制使用​

​。这也是为什么他们会经常一起出现。

简单来说：​

​应用场景不一样​

​

1. OAuth2用在使用第三方账号登录的情况(比如使用weibo, qq, github登录某个app)
2. JWT是用在前后端分离, 需要简单的对后台API进行保护时使用.(前后端分离无session, 频繁传用户密码不安全)

OAuth2是一个相对复杂的协议, 有4种授权模式, 其中的​

​access code模式在实现时可以使用jwt才生成code​

​, 也可以不用. 它们之间没有必然的联系；oauth2有client和scope的概念，jwt没有。如果只是拿来用于颁布token的话，二者没区别。常用的bearer算法oauth、jwt都可以用，只是应用场景不同而已。

JWT 的原理

JWT 的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户，就像下面这样。

​

​javascript { "姓名": "小六六", "角色": "管理员", "到期时间": "2023年7月1日0点0分" }​

​

以后，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名（详见后文）。

服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。

JWT 的数据结构

实际的 JWT 大概就像下面这样。

它是一个很长的字符串，中间用点（​

​.​

​）分隔成三个部分。注意，JWT 内部是没有换行的，这里只是为了便于展示，将它写成了几行。

JWT 的三个部分依次如下。

• Header（头部）
• Payload（负载）
• Signature（签名）

写成一行，就是下面的样子。它是一个很长的字符串，中间用点（​

​.​

​）分隔成三个部分。注意，JWT 内部是没有换行的，这里只是为了便于展示，将它写成了几行。

JWT 的三个部分依次如下。

• Header（头部）
• Payload（负载）
• Signature（签名）

写成一行，就是下面的样子。

​

​javascript Header.Payload.Signature​

​

下面依次介绍这三个部分。

Header

Header 部分是一个 JSON 对象，描述 JWT 的元数据，通常是下面的样子。

​

​javascript { "alg": "HS256", "typ": "JWT" }​

​

上面代码中，​

​alg​

​​属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）；​

​type​

​​属性表示这个令牌（token）的类型（type），JWT 令牌统一写为​

​JWT​

​。

Payload

Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。

• iss (issuer)：签发人
• exp (expiration time)：过期时间
• sub (subject)：主题
• aud (audience)：受众
• nbf (Not Before)：生效时间
• iat (Issued At)：签发时间
• jti (JWT ID)：编号

除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子。

​

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

​

注意，JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。

这个 JSON 对象也要使用 Base64URL 算法转成字符串。

Signature

Signature 部分是对前两部分的签名，防止数据篡改。

首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。

​

​javascript HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)​

​

算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（​

​.​

​）分隔，就可以返回给用户。

Base64URL

前面提到，Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似，但有一些小的不同。

JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 ​​api.example.com/?token=xxx）…​​​ 有三个字符​

​+​

​​、​

​/​

​​和​

​=​

​​，在 URL 里面有特殊含义，所以要被替换掉：​

​=​

​​被省略、​

​+​

​​替换成​

​-​

​​，​

​/​

​​替换成​

​_​

​ 。这就是 Base64URL 算法。

​​JWS（JSON Web Signature）​​

JWS 是在 Unsecured JWT 基础上，Header 部分声明签名算法，并添加 Signature 部分。

JWS 通过添加签名，让接收方能够校验 JWT 有效性，签名由 Payload 经过加密算法计算得到。如接收方使用通用的算法、密钥对 Header 和 Payload 加密，得到的密文与 Signature 部分不同，说明 Payload 被篡改。

JWS 的结构与包含了 Signature 部分的 JWT 相同。

JWS 的标头除了 JWT 的标头​

​alg​

​​和​

​typ​

​之外，还有一些扩展标头：

结束