关于java:JWTJWEJWS-JWK-都是什么鬼还傻傻分不清

作者：NinthDevilHunster\
起源：https://www.freebuf.com/artic…

JWT 置信很多小伙伴都晓得，JSON Web Token，如果在我的项目中通过 jjwt 来反对 JWT 的话，可能只须要理解 JWT 一个概念即可，然而当初很多时候咱们可能不是应用 jjwt，而是抉择 nimbus-jose-jwt 库，此时就有可能接触到一些新的概念，如 JWE、JWS。那么 JWE、JWS 以及 JWT 之间是什么关系呢？

最近看到一篇不错的文章讲这个，咱们一起来看下，以下是注释。

一个 JWT，应该是如下模式的：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

这些货色看上很凌乱，然而十分紧凑，并且是可打印的次要用于验证签名的真实性。

JWT 的次要目标是在服务端和客户端之间以平安的形式来转移申明。次要的利用场景如下所示：

认证 Authentication；
受权 Authorization // 留神这两个单词的区别；
联结辨认；
客户端会话（无状态的会话）；
客户端秘密。

JWS：Signed JWT 签名过的 jwt
JWE：Encrypted JWT 局部 payload 通过加密的 jwt；目前加密 payload 的操作不是很遍及；
JWK：JWT 的密钥，也就是咱们常说的 scret；
JWKset：JWT key set 在非对称加密中，须要的是密钥对而非独自的密钥，在后文中会阐释；
JWA：以后 JWT 所用到的密码学算法；
nonsecure JWT：当头部的签名算法被设定为 none 的时候，该 JWT 是不平安的；因为签名的局部空缺，所有人都能够批改。

一个通常你看到的 jwt，由以下三局部组成，它们别离是：

header：次要申明了 JWT 的签名算法；
payload：次要承载了各种申明并传递明文数据；
signture：领有该局部的 JWT 被称为 JWS，也就是签了名的 JWS；没有该局部的 JWT 被称为 nonsecure JWT 也就是不平安的 JWT，此时 header 中申明的签名算法为 none。

三个局部用·宰割。形如 xxxxx.yyyyy.zzzzz 的款式。

{
  "typ": "JWT",
  "alg": "none",
  "jti": "4f1g23a12aa"
}

jwt header 的组成

头通常由两局部组成：令牌的类型，即 JWT，以及正在应用的散列算法，例如 HMAC SHA256 或 RSA。

当然，还有两个可选的局部，一个是 jti，也就是 JWT ID，代表了正在应用 JWT 的编号，这个编号在对应服务端该当惟一。当然，jti 也能够放在 payload 中。

另一个是 cty，也就是 content type。这个比拟少见，当 payload 为任意数据的时候，这个头无需设置，然而当内容也带有 jwt 的时候。也就是嵌套 JWT 的时候，这个值必须设定为 jwt。这种状况比拟少见。

jwt header 的加密算法

加密的形式如下：

base64UrlEncode(header)
>> eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIiwianRpIjoiNGYxZzIzYTEyYWEifQ

JWT payload

{
  "iss": "http://shaobaobaoer.cn",
  "aud": "http://shaobaobaoer.cn/webtest/jwt_auth/",
  "jti": "4f1g23a12aa",
  "iat": 1534070547,
  "nbf": 1534070607,
  "exp": 1534074147,
  "uid": 1,
  "data": {
    "uname": "shaobao",
    "uEmail": "shaobaobaoer@126.com",
    "uID": "0xA0",
    "uGroup": "guest"
  }
}

jwt payload 的组成 payload 通常由三个局部组成，别离是 Registered Claims ; Public Claims ; Private Claims ; 每个申明，都有各自的字段。

Registered Claims

iss【issuer】发布者的 url 地址
sub【subject】该 JWT 所面向的用户，用于解决特定利用，不是罕用的字段
aud【audience】接受者的 url 地址
exp【expiration】该 jwt 销毁的工夫；unix 工夫戳
nbf【not before】该 jwt 的应用工夫不能早于该工夫；unix 工夫戳
iat【issued at】该 jwt 的公布工夫；unix 工夫戳
jti【JWT ID】该 jwt 的惟一 ID 编号

Public Claims 这些能够由应用 JWT 的那些标准化组织依据须要定义，该当参考文档 IANA JSON Web Token Registry。

Private Claims 这些是为在批准应用它们的各方之间共享信息而创立的自定义申明，既不是注册申明也不是公开申明。下面的 payload 中，没有 public claims 只有 private claims。

jwt payload 的加密算法

加密的形式如下：

base64UrlEncode(payload)
>>eyJpc3MiOiJodHRwOi8vc2hhb2Jhb2Jhb2VyLmNuIiwiYXVkIjoiaHR0cDovL3NoYW9iYW9iYW9lci5jbi93ZWJ0ZXN0L2p3dF9hdXRoLyIsImp0aSI6IjRmMWcyM2ExMmFhIiwiaWF0IjoxNTM0MDcwNTQ3LCJuYmYiOjE1MzQwNzA2MDcsImV4cCI6MTUzNDA3NDE0NywidWlkIjoxLCJkYXRhIjp7InVuYW1lIjoic2hhb2JhbyIsInVFbWFpbCI6InNoYW9iYW9iYW9lckAxMjYuY29tIiwidUlEIjoiMHhBMCIsInVHcm91cCI6Imd1ZXN0In19

裸露的信息

所以，在 JWT 中，不应该在载荷外面退出任何敏感的数据。在下面的例子中，咱们传输的是用户的 User ID，邮箱等。这个值实际上不是什么敏感内容，个别状况下被晓得也是平安的。然而像明码这样的内容就不能被放在 JWT 中了。如果将用户的明码放在了 JWT 中，那么怀有歹意的第三方通过 Base64 解码就能很快地晓得你的明码了。

当然，这也是有解决方案的，那就是加密 payload。在之后会说到.

JWS，也就是 JWT Signature，其构造就是在之前 nonsecure JWT 的根底上，在头部申明签名算法，并在最初增加上签名。创立签名，是保障 jwt 不能被别人随便篡改。

为了实现签名，除了用到 header 信息和 payload 信息外，还须要算法的密钥，也就是 secret。当利用非对称加密办法的时候，这里的 secret 为私钥。

为了不便后文的开展，咱们把 JWT 的密钥或者密钥对，对立称为 JSON Web Key，也就是 JWK。

jwt signature 的签名算法

RSASSA || ECDSA || HMACSHA256(base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)
>>GQPGEpixjPZSZ7CmqXB-KIGNzNl4Y86d3XOaRsfiXmQ
>># 下面这个是用 HMAC SHA256 生成的

到目前为止，jwt 的签名算法有三种。

对称加密 HMAC【哈希音讯验证码】：HS256/HS384/HS512
非对称加密 RSASSA【RSA 签名算法】（RS256/RS384/RS512）
ECDSA【椭圆曲线数据签名算法】（ES256/ES384/ES512）

最初将签名与之前的两段内容用. 连贯，就能够失去通过签名的 JWT，也就是 JWS。

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImp0aSI6IjRmMWcyM2ExMmFhIn0.eyJpc3MiOiJodHRwOi8vc2hhb2Jhb2Jhb2VyLmNuIiwiYXVkIjoiaHR0cDovL3NoYW9iYW9iYW9lci5jbi93ZWJ0ZXN0L2p3dF9hdXRoLyIsImp0aSI6IjRmMWcyM2ExMmFhIiwiaWF0IjoxNTM0MDcwNTQ3LCJuYmYiOjE1MzQwNzA2MDcsImV4cCI6MTUzNDA3NDE0NywidWlkIjoxLCJkYXRhIjp7InVuYW1lIjoic2hhb2JhbyIsInVFbWFpbCI6InNoYW9iYW9iYW9lckAxMjYuY29tIiwidUlEIjoiMHhBMCIsInVHcm91cCI6Imd1ZXN0In19.GQPGEpixjPZSZ7CmqXB-KIGNzNl4Y86d3XOaRsfiXmQ

当验证签名的时候，利用公钥或者密钥来解密 Sign，和 base64UrlEncode(header) + “.” + base64UrlEncode(payload) 的内容齐全一样的时候，示意验证通过。

如果对于 CA 有些概念的话，这些内容会比拟好了解一些。为了确保服务器的密钥对牢靠无效，同时也不便第三方 CA 机构来签订 JWT 而非本机服务器签订 JWT，对于 JWS 的头部，能够有额定的申明，以下申明是可选的，具体取决于 JWS 的应用形式。如下所示：

jku: 发送 JWK 的地址；最好用 HTTPS 来传输
jwk: 就是之前说的 JWK
kid: jwk 的 ID 编号
x5u: 指向一组 X509 公共证书的 URL
x5c: X509 证书链
x5t：X509 证书的 SHA- 1 指纹
x5t#S256: X509 证书的 SHA-256 指纹
typ: 在本来未加密的 JWT 的根底上减少了 JOSE 和 JOSE+ JSON。JOSE 序列化后文会说及。实用于 JOSE 标头的对象与此 JWT 混合的状况。
crit: 字符串数组，蕴含申明的名称，用作实现定义的扩大，必须由 this->JWT 的解析器解决。不常见。

当须要多重签名或者 JOSE 表头的对象与 JWS 混合的时候，往往须要用到 JWS 的序列化。JWS 的序列化构造如下所示:

{
    "payload": "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"signatures":
    [
        {
            "protected": "eyJhbGciOiJSUzI1NiJ9",
            "header": {"kid": "2010-12-29"},
            "signature":"signature1"
        },
        {
            "protected": "eyJhbGciOiJSUzI1NiJ9",
            "header": {"kid": "e9bc097a-ce51-4036-9562-d2ade882db0d"},
            "signature":"signature2"
        },
        ...
    ]
}

构造很容易了解。首先是 payload 字段，这个不必多讲，之后是 signatures 字段，这是一个数组，代表着多个签名。每个签名的构造如下：

protected：之前的头部申明，利用 b64uri 加密；
header：JWS 的额定申明，这段内容不会放在签名之中，无需验证；
signature：也就是对以后 header+payload 的签名。

JWE 是一个很新的概念，总之，除了 jwt 的官网手册外，很少有网站或者博客会介绍这个货色。也并非所有的库都反对 JWE。这里记录一下本人看官网手册后了解下来的货色。

JWS 是去验证数据的，而 JWE（JSON Web Encryption）是爱护数据不被第三方的人看到的。通过 JWE，JWT 变得更加平安。

JWE 和 JWS 的公钥私钥计划不雷同，JWS 中，私钥持有者加密令牌，公钥持有者验证令牌。而 JWE 中，私钥一方应该是惟一能够解密令牌的一方。

在 JWE 中，公钥持有能够将新的数据放入 JWT 中，然而 JWS 中，公钥持有者只能验证数据，不能引入新的数据。因而，对于公钥 / 私钥的计划而言，JWS 和 JWE 是互补的。

一个 JWE，应该是如下模式的：

eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm1NJn8LE9XShH59_
i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7PcHALUzoOegEI-8E66jX2E4zyJKxYxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIFNPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8Otv
zlV7elprCbuPhcCdZ6XDP0_F8rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTPcFPgwCp6X-nZZd9OHBv-B3oWh2TbqmScqXMR4gp_A.
AxY8DCtDaGlsbGljb3RoZQ.
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.
9hH0vgRfYgPnAHOd8stkvw

如你所见 JWE 一共有五个局部，别离是：

The protected header，相似于 JWS 的头部；
The encrypted key，用于加密密文和其余加密数据的对称密钥；
The initialization vector，初始 IV 值，有些加密形式须要额定的或者随机的数据；
The encrypted data (cipher text)，密文数据；
The authentication tag，由算法产生的附加数据，来避免密文被篡改。

一般来说，JWE 须要对密钥进行加密，这就意味着同一个 JWT 中至多有两种加密算法在起作用。然而并非将密钥拿来就能用，咱们须要对密钥进行加密后，利用 JWK 密钥管理模式来导出这些密钥。JWK 的管理模式有以下五种，别离是：

Key Encryption
Key Wrapping
Direct Key Agreement
Key Agreement with Key Wrapping
Direct Encryption

并不是所有的 JWA 都可能反对这五种密钥治理管理模式，也并非每种密钥管理模式之间都能够互相转换。能够参考 Spomky-Labs/jose 中给出的表格：

https://github.com/Spomky-Lab…

至于各个密钥管理模式的细节，还请看 JWT 的官网手册，解释起来较为简单。

就如同是 JWS 的头部一样。JWE 的头部也有着本人规定的额定申明字段，如下所示：

type：个别是 jwt
alg：算法名称，和 JWS 雷同，该算法用于加密稍后用于加密内容的理论密钥
enc：算法名称，用上一步生成的密钥加密内容的算法。
zip：加密前压缩数据的算法。该参数可选，如果不存在则不执行压缩，通常的值为 DEF，也就是 deflate 算法
jku/jkw/kid/x5u/x5c/x5t/x5t#S256/typ/cty/crit：和 JWS 额额定申明一样。

步骤 2 和步骤 3，更具不同的密钥管理模式，应该有不同的解决形式。在此只列举一些通常状况。

之前谈及，JWE 一共有五个局部。当初来具体说一下加密的过程：

依据头部 alg 的申明，生成肯定大小的随机数；
依据密钥管理模式确定加密密钥；
依据密钥管理模式确定 JWE 加密密钥，失去 CEK；
计算初始 IV，如果不须要，跳过此步骤；
如果 ZIP 头申明了，则压缩明文；
应用 CEK，IV 和附加认证数据，通过 enc 头申明的算法来加密内容，后果为加密数据和认证标记；
压缩内容，返回 token。

base64(header) + '.' +base64(encryptedKey) + '.' + // Steps 2 and 3base64(initializationVector) + '.' + // Step 4base64(ciphertext) + '.' + // Step 6base64(authenticationTag) // Step 6

和 JWS 相似，JWE 也定义了紧凑的序列化格局，用来实现多种形式的加密。大抵格局如下所示：

{
    "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
    "unprotected": {"jku":"https://server.example.com/keys.jwks"},
    "recipients":[
        {"header": { "alg":"RSA1_5","kid":"2011-04-29"},
        "encrypted_key":
        "UGhIOguC7Iu...cqXMR4gp_A"
        },
        {"header": { "alg":"A128KW","kid":"7"},
        "encrypted_key": "6KB707dM9YTIgH...9locizkDTHzBC2IlrT1oOQ"
        }
    ],
    "iv": "AxY8DCtDaGlsbGljb3RoZQ",
    "ciphertext": "KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
    "tag": "Mz-VPPyU4RlcuYv1IwIvzw"
}

构造很容易了解，如下所示：

protected：之前的头部申明，利用 b64uri 加密；
unprotected：个别放 JWS 的额定申明，这段内容不会被 b64 加密；
iv：64 加密后的 iv 参数；
add：额定认证数据；
ciphertext：b64 加密后的加密数据；
recipients：b64 加密后的认证标志 - 加密链，这是一个数组，每个数组中蕴含了两个信息；
header：次要是申明以后密钥的算法；
encrypted_key：JWE 加密密钥。

这里通过 juice shop 来说下 jwt 是如何工作的。在身份验证中，当用户应用其凭据胜利登录时，将返回 JSON Web 令牌。如下所示：往此时，返回了 jwt 的令牌。

每当用户想要拜访受爱护的路由或资源时，用户将应用承载【bearer】模式发送 JWT，通常在 Authorization 标头中。题目的内容应如下所示：

Authorization: Bearer <token>

随后，服务器会取出 token 中的内容，来返回对应的内容。须知，这个 token 不肯定会贮存在 cookie 中，如果存在 cookie 中的话，须要设置为 http-only，避免 XSS。另外，还能够放在别的中央，比方 localStorage、sessionStorage。如果应用 vue 的话，还能够存在 vuex 外面。

另外，如果在如 Authorization: Bearer 中发送令牌，则跨域资源共享（CORS）将不会成为问题，因为它不应用 cookie。

此时，去拜访认证页面，申请头如下所示，如预期所见，是利用 Authorization:Bearer 的申请头去拜访的。

之前看 JWT 的时候看到论坛里的一个话题，觉得很有意思，用本人的了解来说一下：

https://stackoverflow.com/que…。

首先，咱们必须明确一点，无论用的是 HMAC，RSASSA，ECDSA；密钥，公钥，私钥都不会发送给客户端，仅仅会保留在服务端上。

对称的算法 HMAC 实用于单点登录，一对一的场景中。速度很快。

然而面对一对多的状况，比方一个 APP 中的不同服务模块，须要 JWT 登录的时候，主服务端【APP】领有一个私钥来实现签名即可，而用户带着 JWT 在拜访不同服务模块【副服务端】的时候，副服务端只有用公钥来验证签名就能够了。从肯定水平上也缩小了主服务端的压力。

当然，还有一种状况就是不同成员进行开发的时候，大家能够用对立的私钥来实现签名，而后用各自的公钥去实现对 JWT 的认证，也是一种十分好的开发伎俩。

因而，构建一个没有多个小型“微服务应用程序”的应用程序，并且开发人员只有一组的，抉择 HMAC 来签名即可。其余状况下，尽量抉择 RSA。

近期热文举荐：

1.1,000+ 道 Java 面试题及答案整顿 (2021 最新版)

2. 别在再满屏的 if/ else 了，试试策略模式，真香！！

3. 卧槽！Java 中的 xx ≠ null 是什么新语法？

4.Spring Boot 2.5 重磅公布，光明模式太炸了！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！

关于java:JWTJWEJWS-JWK-都是什么鬼还傻傻分不清

JWT

什么是 JWT

JWT 解决什么问题？

JWT 的一些名词解释

JWT 的组成

JWT header

JWS

JWS 的概念

JWS 的额定头部申明

多重验证与 JWS 序列化

JWE

JWE 相干概念

JWE 的形成

JWE 密钥加密算法

JWE Header

JWE 的加密过程

多重验证与 JWE 序列化

JWT 的工作原理

ECDSA|RSASSA or HMAC？应该选用哪个？