我正在围绕 JWT 创建和验证编写一些单元和集成测试。我正在使用我用 openssl 创建的真实(良好自签名)证书拼凑一个快速 JWKS 页面,我一直在做饭,直到遇到这个非常简单的问题:
“E”值是 65537,但在 JWKS 中它应该是 AQAB。在墙上敲了很长时间后,我终于在纸上弄清楚了。
https://www.rfc-editor.org/rfc/rfc7518#section-6.3.1.2
65537 是 0000 0001: 0000 0000 : 0000 0001
如果您将其转换为 base64 的 6 位,您将得到
000000 010000 000000 000001
哪个是 AQAB
https://en.wikipedia.org/wiki/Base64#Base64_table
所以我尝试编写一些快速代码。但事实证明它并不快。我在想,一定有更简单的方法。我尝试的所有 base64 编码都给了我超过 3 个字节的空间。
任何有自尊的程序员都会做的事情也是如此……我看到每个人都使用 65537,所以我对那个傻瓜进行了硬编码并继续前进,但它一直在唠叨我。我讨厌困扰我的问题。
我得到的最接近的是:
bs := make([]byte, 4)
binary.BigEndian.PutUint32(bs, 65537)
fmt.Println(bs)
fmt.Println(base64.URLEncoding.EncodeToString(bs))
其中产生:
[0 1 0 1]
AAEAAQ==
我的快速数学说,base64 输出是为什么超过 3 个字节:D
饮歌长啸
相关分类