首页 文章

JWT Base64解码在记事本中失败

提问于
浏览 次
3

在Notepad++中，我在解码JWT时遇到问题 . 当我尝试使用 Plugins -> MIME Tools -> Base64 Decode 时：

eyJleHAiOjE0NDIzNjAwMzQsIm5iZiI6MTQ0MjM1NjQzNCwidmVyIjoiMS4wIiwiaXNzIjoiaHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tLzc3NTUyN2ZmLTlhMzctNDMwNy04YjNkLWNjMzExZjU4ZDkyNS92Mi4wLyIsImFjciI6ImIyY18xX3NpZ25faW5fc3RvY2siLCJzdWIiOiJOb3Qgc3VwcG9ydGVkIGN1cnJlbnRseS4gVXNlIG9pZCBjbGFpbS4iLCJhdWQiOiI5MGMwZmU2My1iY2YyLTQ0ZDUtOGZiNy1iOGJiYzBiMjlkYzYiLCJpYXQiOjE0NDIzNTY0MzQsImF1dGhfdGltZSI6MTQ0MjM1NjQzNCwiaWRwIjoiZmFjZWJvb2suY29tIn0

我明白了：

要解码的所选文本（不包括EOL）的长度无效 . 它应该是mod 4 .

但如果使用www.base64decode.org它工作正常：

{“exp”：1442360034，“nbf”：1442356434，“ver”：“1.0”，“iss”：“https：//login.microsoftonline.com/775527ff-9a37-4307-8b3d-cc311f58d925/v2.0 /“，”acr“：”b2c_1_sign_in_stock“，”sub“：”目前不支持 . 使用oid声明 . “，”aud“：”90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6“，”iat“：1442356434，”auth_time “：1442356434，” IDP “：” facebook.com“}

这是为什么？我错误地使用记事本了吗？

我正在使用的值来自Azure AD B2C: Token reference .

notepad++ jwt azure-ad-b2c

3 回答

  • 3

    Short answer:

    要使字符串可解码，您必须使编码字符串中的字符数为4的整数倍 . 这意味着您必须将字符数除以4而不是余数 . 在这种特殊情况下，您有443个字符 . 最后添加 = 将使其可解码 .

    Long answer:

    Base64编码使用称为填充的东西 . 输出中的字符数必须是4的整数倍 . 如果实际输出不满足该要求，则编码算法将向输出添加其他填充字符 . 填充字符通常是 = .

    在Wikipedia上有一些关于它是如何工作的例子 . 你也可以看到this SO帖子 .

    "ordinary" base64url编码与JWT使用的base64url编码之间存在差异：JWT会跳过填充字符 . 它们根本就没有添加 . 因此，JWT的任何解码算法都必须考虑到这一事实 .

    普通的base64解码器不允许没有填充的编码字符串作为输入（如果需要填充） . 大多数解码器在解码算法开始时都有一个断言，它们检查输入字符串的长度并检查长度％4 = 0.您可以从错误消息中看到

    Length of selected text (not including EOL) to be decoded is invalid. It should be mod 4.

    长度错误，因为缺少填充字符 .

    因此，使用处理无垫字符串的解码器是可行的方法 . 安德烈已经链接了一个网站Here是另一个 .

    回复于
  • 1

    JWT使用"base64url"编码，使用URL安全字母表 .

    "base64url"编码是Base 64编码，其中URL保留字符被替换（例如 - 替换 + 和 _ 替换 / ）并且删除了填充字符 .

    回复于
  • 4

    上面的标记在Azure B2C doc indicated中不一样，看起来无效 . 除非这个问题是关于记事本的，否则我建议使用像https://jwt.ms这样的网站来解码令牌 . jwt.ms不仅可以帮助您解码令牌，还可以了解每个声明的含义 .

    回复于

相关问题