只知道JWT，那JWE、JWS、JWK、JWA呢？

举报
码农小胖哥 发表于 2022/03/31 23:14:56 2022/03/31
【摘要】 2022年的开工福利已经发布，点击下面按钮获取最新PDF。 移动端兴起和OAuth2的流行导致JWT这几年火得一塌糊涂。今天要介绍另一个规范集JOSE[1],全称Javascript Object Signing and Encryption，它和JWT有莫大的关系。 JOSE简介 JOSE是一个Javascript...

6b4d12a036871c3031b4d8754c16e956.gif

2022年的开工福利已经发布，点击下面按钮获取最新PDF。

e917a9bc09ddc87e253ff1b481572fa9.png

移动端兴起和OAuth2的流行导致JWT这几年火得一塌糊涂。今天要介绍另一个规范集JOSE[1],全称Javascript Object Signing and Encryption，它和JWT有莫大的关系。

JOSE简介

JOSE是一个Javascript对象签名和加密协议，目的是提供一种在各个通讯方之间安全传输声明（ claims，例如授权信息 ）的方法，它特意构建在JSON和BASE64之上，以便在 Web应用程序中轻松使用。目前该规范还在不断地发展，我们常用的包含以下几个由RFC文档定义的概念：

90fe4e1a43b40670ff765c392c0a7917.png JOSE规范集
❝

JWT就可以用JWS或JWE表示，稍后我会详细介绍这一方面的知识。

JWS

JSON Web签名，基于JSON数据结构、使用数字签名技术或者消息认证码技术保护的内容（MAC）都可以称为JWS。该规范使用的密码算法和标识符在另一个规范JWA中定义。规则是比较多的参见RFC7515[2]，这里我们通过序列化来感受一下即可。

JWS 序列化

JWS的序列化分为JWS Compact Serialization和JWS JSON Serialization两种。

JWS Compact Serialization

该序列化表示为一种URL安全的、紧凑的字符串。格式为：


   
    
    
  1. 
     
    
      
    
     
    
     
    
      
    
       BASE64URL(UTF8(JWS Protected Header)) || '.' ||
      
    
     
    2. 
    
  2. 
     
    
      
    
     
    
     
    
      
    
             BASE64URL(JWS Payload) || '.' ||
      
    
     
    3. 
    
  3. 
     
    
      
    
     
    
     
    
      
    
             BASE64URL(JWS Signature)
      
    
     
    4.

例如：

eyJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q
❝

JWT通常就是这种格式。

JWS JSON Serialization

该序列化表示为一个JSON对象，有两种格式。一般格式为：


   
    
    
  1. 
     
    
      
    
     
    
     
    
      
    
       {
      
    
     
    2. 
    
  2. 
     
    
      
    
     
    
     
    
      
    
             "payload":"<payload contents>",
      
    
     
    3. 
    
  3. 
     
    
      
    
     
    
     
    
      
    
             "signatures":[
      
    
     
    4. 
    
  4. 
     
    
      
    
     
    
     
    
      
    
              {"protected":"<integrity-protected header 1 contents>",
      
    
     
    5. 
    
  5. 
     
    
      
    
     
    
     
    
      
    
               "header":"<non-integrity-protected header 1 contents>“,
      
    
     
    6. 
    
  6. 
     
    
      
    
     
    
     
    
      
    
               "signature":"<signature 1 contents>"},
      
    
     
    7. 
    
  7. 
     
    
      
    
     
    
     
    
      
    
              {"protected":"<integrity-protected header N contents>",
      
    
     
    8. 
    
  8. 
     
    
      
    
     
    
     
    
      
    
               "header":"<non-integrity-protected header N contents>",
      
    
     
    9. 
    
  9. 
     
    
      
    
     
    
     
    
      
    
               "signature":"<signature N contents>"}]
      
    
     
    10. 
    
  10. 
     
    
      
    
     
    
     
    
      
    
            }
      
    
     
    11.

平铺格式为：


   
    
    
  1. 
     
    
      
    
     
    
     
    
      
    
       {
      
    
     
    2. 
    
  2. 
     
    
      
    
     
    
     
    
      
    
             "payload":"<payload contents>",
      
    
     
    3. 
    
  3. 
     
    
      
    
     
    
     
    
      
    
             "protected":"<integrity-protected header contents>",
      
    
     
    4. 
    
  4. 
     
    
      
    
     
    
     
    
      
    
             "header":"<non-integrity-protected header contents>",
      
    
     
    5. 
    
  5. 
     
    
      
    
     
    
     
    
      
    
             "signature":"<signature contents>"
      
    
     
    6. 
    
  6. 
     
    
      
    
     
    
     
    
      
    
            }
      
    
     
    7.

举个一般格式的例子：


   
    
    
  1. 
     
    
      
    
     
    
     
    
      
    
       {
      
    
     
    2. 
    
  2. 
     
    
      
    
     
    
     
    
      
    
             "payload":
      
    
     
    3. 
    
  3. 
     
    
      
    
     
    
     
    
      
    
              "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
      
    
     
    4. 
    
  4. 
     
    
      
    
     
    
     
    
      
    
               tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
      
    
     
    5. 
    
  5. 
     
    
      
    
     
    
     
    
      
    
             "signatures":[
      
    
     
    6. 
    
  6. 
     
    
      
    
     
    
     
    
      
    
              {"protected":"eyJhbGciOiJSUzI1NiJ9",
      
    
     
    7. 
    
  7. 
     
    
      
    
     
    
     
    
      
    
               "header":
      
    
     
    8. 
    
  8. 
     
    
      
    
     
    
     
    
      
    
                {"kid":"2010-12-29"},
      
    
     
    9. 
    
  9. 
     
    
      
    
     
    
     
    
      
    
               "signature":
      
    
     
    10. 
    
  10. 
     
    
      
    
     
    
     
    
      
    
                "cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ
      
    
     
    11. 
    
  11. 
     
    
      
    
     
    
     
    
      
    
                 mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb
      
    
     
    12. 
    
  12. 
     
    
      
    
     
    
     
    
      
    
                 KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl
      
    
     
    13. 
    
  13. 
     
    
      
    
     
    
     
    
      
    
                 b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES
      
    
     
    14. 
    
  14. 
     
    
      
    
     
    
     
    
      
    
                 c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX
      
    
     
    15. 
    
  15. 
     
    
      
    
     
    
     
    
      
    
                 LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"},
      
    
     
    16. 
    
  16. 
     
    
      
    
     
    
     
    
      
    
              {"protected":"eyJhbGciOiJFUzI1NiJ9",
      
    
     
    17. 
    
  17. 
     
    
      
    
     
    
     
    
      
    
               "header":
      
    
     
    18. 
    
  18. 
     
    
      
    
     
    
     
    
      
    
                {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
      
    
     
    19. 
    
  19. 
     
    
      
    
     
    
     
    
      
    
               "signature":
      
    
     
    20. 
    
  20. 
     
    
      
    
     
    
     
    
      
    
                "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
      
    
     
    21. 
    
  21. 
     
    
      
    
     
    
     
    
      
    
                 lSApmWQxfKTUJqPP3-Kg6NU1Q"}]
      
    
     
    22. 
    
  22. 
     
    
      
    
     
    
     
    
      
    
       }
      
    
     
    23.

JWE

JWS 仅仅是对声明(claims)作了签名，保证了其不被篡改，但是其 payload(中段负载) 信息是暴露的。也就是 JWS 仅仅能保证数据的完整性而不能保证数据不被泄露。它不适合传递敏感数据。JWE 的出现就是为了解决这个问题的。具体的可以看下图：

735fd7324c986cf462cb3352d5aef016.png JWE示意图

从上面可以看出 JWE 的生成非常繁琐，作为 Token 可能比较消耗资源和耗时。用作安全的数据传输途径应该不错。举个例子：


   
    
    
  1. 
     
    
      
    
     
    
     
    
      
    
       eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
      
    
     
    2. 
    
  2. 
     
    
      
    
     
    
     
    
      
    
            OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
      
    
     
    3. 
    
  3. 
     
    
      
    
     
    
     
    
      
    
            ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
      
    
     
    4. 
    
  4. 
     
    
      
    
     
    
     
    
      
    
            Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
      
    
     
    5. 
    
  5. 
     
    
      
    
     
    
     
    
      
    
            mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
      
    
     
    6. 
    
  6. 
     
    
      
    
     
    
     
    
      
    
            1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
      
    
     
    7. 
    
  7. 
     
    
      
    
     
    
     
    
      
    
            6UklfCpIMfIjf7iGdXKHzg.
      
    
     
    8. 
    
  8. 
     
    
      
    
     
    
     
    
      
    
            48V1_ALb6US04U3b.
      
    
     
    9. 
    
  9. 
     
    
      
    
     
    
     
    
      
    
            5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
      
    
     
    10. 
    
  10. 
     
    
      
    
     
    
     
    
      
    
            SdiwkIr3ajwQzaBtQD_A.
      
    
     
    11. 
    
  11. 
     
    
      
    
     
    
     
    
      
    
            XFBoMYUZodetZdvTiFvSkQ
      
    
     
    12.

一共有五个部分，被四个英文句号隔开。

❝

其实JWE也有对应的JSON格式，同样具有JWS的两种序列化方式，参见RFC7516[3]。

JWT和JWS、JWE的关系

以下是RFC7519[4]对JWT的说明：

343ee7c6eb4d733738af627246c5af57.png JWT的定义

从上面可以得出一些结论：

  • JWT有特定的 claims，这些claims以JSON的形式组成Payload。

  • JWT的结构可以是JWS或者JWE。

  • JWT的序列化方式只能使用Compact Serialization，不能是JSON Serialization。

简而言之，JWT是包含了特定claims的JWS或者JWE字符串。我们常见的大部分都属于JWS。

❝

另外，我们通常读作J、W、T，实际建议读作jot（角特），关于JWT的定义和规范请参阅RFC7519[5]。

JWK

JWK是本文最重要的知识点，这对我们后面学习资源服务器（Resource Server）非常重要。

场景描述

我相信签名公私钥这个大家都不陌生。JWT本身也要做使用私钥进行签名防止信息被篡改，公钥用来发给下游消费方来验证JWT的可靠性。通常情况下，公钥的配置方式为静态文件集成，这有一个弊端，当上游公私钥进行了改动，下游就无法动态进行公钥适配。这就是JWK要解决的问题，它对密码算法和标识符进行了规范设计，它紧凑的JSON数据结构非常方便在上下游之间传输。

JWK 格式

JWK是表示加密密钥的JSON对象。该对象包含的key名称必须是唯一的，在此基础上JWK可以包含一些自定义字段。下面是一个P-256 EC（椭圆曲线离散密码）密钥的JWK表示：


   
    
    
  1. 
     
    
      
    
     
    
     
    
      
    
       {"kty":"EC",
      
    
     
    2. 
    
  2. 
     
    
      
    
     
    
     
    
      
    
             "crv":"P-256",
      
    
     
    3. 
    
  3. 
     
    
      
    
     
    
     
    
      
    
             "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
      
    
     
    4. 
    
  4. 
     
    
      
    
     
    
     
    
      
    
             "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
      
    
     
    5. 
    
  5. 
     
    
      
    
     
    
     
    
      
    
             "kid":"Public key used in JWS spec Appendix A.3 example"
      
    
     
    6. 
    
  6. 
     
    
      
    
     
    
     
    
      
    
            }
      
    
     
    7.

按照RFC7517[6]的定义，JWK JSON对象可能包含以下属性：

eb610510436ee37116710dcc82eeeb93.png JWK的定义属性
❝

根据不同的算法JWK还可能包含其它的属性。

JWK Set

JWK Set 表示一组具有不同kid的JWK，这非常容易理解。它也是一个JSON对象，唯一的key就是keys。举个例子：


   
    
    
  1. 
     
    
      
    
     
    
     
    
      
    
       {"keys":
      
    
     
    2. 
    
  2. 
     
    
      
    
     
    
     
    
      
    
              [
      
    
     
    3. 
    
  3. 
     
    
      
    
     
    
     
    
      
    
                {"kty":"EC",
      
    
     
    4. 
    
  4. 
     
    
      
    
     
    
     
    
      
    
                 "crv":"P-256",
      
    
     
    5. 
    
  5. 
     
    
      
    
     
    
     
    
      
    
                 "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
      
    
     
    6. 
    
  6. 
     
    
      
    
     
    
     
    
      
    
                 "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
      
    
     
    7. 
    
  7. 
     
    
      
    
     
    
     
    
      
    
                 "use":"enc",
      
    
     
    8. 
    
  8. 
     
    
      
    
     
    
     
    
      
    
                 "kid":"1"},
      
    
     
    9. 
    
  9. 
     
    
      
    
     
    
     
    
      
     
      
    
     
    10. 
    
  10. 
     
    
      
    
     
    
     
    
      
    
                {"kty":"RSA",
      
    
     
    11. 
    
  11. 
     
    
      
    
     
    
     
    
      
    
                 "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
      
    
     
    12. 
    
  12. 
     
    
      
    
     
    
     
    
      
    
            4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
      
    
     
    13. 
    
  13. 
     
    
      
    
     
    
     
    
      
    
            tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
      
    
     
    14. 
    
  14. 
     
    
      
    
     
    
     
    
      
    
            QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
      
    
     
    15. 
    
  15. 
     
    
      
    
     
    
     
    
      
    
            SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
      
    
     
    16. 
    
  16. 
     
    
      
    
     
    
     
    
      
    
            w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
      
    
     
    17. 
    
  17. 
     
    
      
    
     
    
     
    
      
    
                 "e":"AQAB",
      
    
     
    18. 
    
  18. 
     
    
      
    
     
    
     
    
      
    
                 "alg":"RS256",
      
    
     
    19. 
    
  19. 
     
    
      
    
     
    
     
    
      
    
                 "kid":"2011-04-29"}
      
    
     
    20. 
    
  20. 
     
    
      
    
     
    
     
    
      
    
              ]
      
    
     
    21. 
    
  21. 
     
    
      
    
     
    
     
    
      
    
            }
      
    
     
    22.
❝

OAuth2配置中的JWK Set URL就是输出JWK Set的端点。

JWA

JWA规范规定了哪些算法可以作为JWS和JWE的密码算法。还规定了这些算法对应的JWK中的alg属性，以及特定算法在JWK包含的属性例如前面EC算法中的crv、x、y，这些属性并不是一成不变的，它们会根据算法的迭代进行调整。如果你对JWA的细节感兴趣，请参阅RFC7518[7]。

❝

你可以通过JWK生成器[8]自行使用一些算法生成JWK观察不同算法之间的区别。

小结

今天对JOSE规范进行简单的介绍了解，对你学习OAuth2和OIDC相关的知识非常有帮助。不要求深入但是一定要了解相关的知识。

参考资料

[1]

JOSE: https://datatracker.ietf.org/wg/jose/documents/

[2]

RFC7515: https://datatracker.ietf.org/doc/rfc7515/

[3]

RFC7516: https://datatracker.ietf.org/doc/rfc7516/

[4]

RFC7519: https://datatracker.ietf.org/doc/rfc7519/

[5]

RFC7519: https://datatracker.ietf.org/doc/rfc7519/

[6]

RFC7517: https://datatracker.ietf.org/doc/rfc7517/

[7]

RFC7518: https://datatracker.ietf.org/doc/rfc7518/

[8]

JWK生成器: https://mkjwk.org/

Spring Security即将弃用配置类WebSecurityConfigurerAdapter

2022-02-22

0513ac63f8fe68d514c61a2855ccaf23.png

Spring Security的内置过滤器是如何维护的

2022-02-21

312697453070f6da90b854c69066fcef.png

欢迎加入胖哥技术内卷群

2022-02-22

319916b21305a996b3215ef9ddc963ab.png

008217e2ae7ab8a6cc5e770b86aaa2b9.gif

文章来源: felord.blog.csdn.net，作者：码农小胖哥，版权归原作者所有，如需转载，请联系作者。

原文链接：felord.blog.csdn.net/article/details/123243984

【版权声明】本文为华为云社区用户转载文章，如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱： cloudbbs@huaweicloud.com
JSON
  • 点赞
  • 收藏
  • 关注作者

评论（0）

0/1000
抱歉，系统识别当前为高风险访问，暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称，即可参与社区互动！

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

确认 取消

加入云驻计划，成为创作者

  • 华为云周边好礼
  • 免费体验产品
  • 特殊身份标识
  • 线下官方门票
  • 内部专家零距离
  • 与10000+优质创作者共同成长
立即加入