前言
上一篇文章我们已经看了iOS StoreKit 2 今天我们来看看 他们的加密算法JWS
聊聊JWT和OAuth2
要比较JWT和OAuth2，首先要明白一点就是，这两个根本没有可比性，是两个完全不同的东西。
JWT是一种认证协议
JWT提供了一种用于发布接入令牌（Access Token),并对发布的签名接入令牌进行验证的方法。 令牌（Token）本身包含了一系列声明，应用程序可以根据这些声明限制用户对资源的访问。
OAuth2是一种授权框架
另一方面，OAuth2是一种授权框架，提供了一套详细的授权机制（指导）。用户或应用可以通过公开的或私有的设置，授权第三方应用访问特定资源。
为什么要比较
既然JWT和OAuth2没有可比性，为什么还要把这两个放在一起说呢？实际中确实会有很多人拿JWT和OAuth2作比较。很多情况下，在讨论OAuth2的实现时，会把JSON Web Token作为一种认证机制使用。这也是为什么他们会经常一起出现。
简单来说：应用场景不一样
- OAuth2用在使用第三方账号登录的情况(比如使用weibo, qq, github登录某个app)
- 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之外，还有一些扩展标头：
非对称加密算法加密的 Signature，发布方使用私钥进行签名，接收方可以使用公钥校验 Header 与 Payload（解密 Signature 校验）。
对称加密算法要求接收方拥有与 JWS 发布方相同的密钥，接收方使用相同的密钥校验 Header 与 Payload（加密 Payload 校验）。
结束
好了，JWT，JWS相关的内容就到这了,给大家科普下
