我能够在 Azure AD 身份验证中请求令牌。但问题是每当我更改 access_token 中的最后一个字符时，它仍然在我的 API 中成功请求。我只是关注这个https://mehmetkut.com/2017/05/protect-aspnetcore-webapi-resources-with-azure-active-directory-en/ 有没有办法可以验证令牌？它仅在我更改最后一个字符的至少 1 个时发生。
https://mehmetkut.com/2017/05/protect-aspnetcore-webapi-resources-with-azure-active-directory-en/
即使我更改了最后一个字符，令牌仍然有效。
【问题讨论】：
标签： azure oauth-2.0 azure-active-directory
有趣的是，我们也在安全审计中发现了这一点。
事实证明，签名的最后 4 位只是填充而不是签名的一部分。 所以某些字符将被接受为最后一个字符，而不是全部。 在这种情况下，您实际上并没有修改签名数据，只是修改了填充。
这是一个比我聪明的人的解释：
这是base64解码的副作用，解码后的事实 签名是 256 字节长，而 256 留下 a 的事实仍然存在 除以 3 时为 1。?
RS256 alg 值对应于“使用 RSASSA-PKCS1-v1_5 SHA-256”算法，生成的签名为 256 字节 长，然后在构造 JWT 时进行 base64url 编码， 在第二个“.”之后产生 342 个字符。前 255 个字节 未编码的签名全部“适合”到 340 个字符中 base64（每 6 位输入产生 1 个编码字符）。来自 签名的最后一个字节，前 6 位给出第 341 个字符 的编码签名。现在我们只剩下两位要编码了。 由于我们需要 6 位来获得一个 base64 编码的字符，我们追加 四个 0 给我们 6 位，并正常编码。
解码时，我们从左边开始，将每个字符转换为它的 二进制的 base64 索引（例如，“A”是 000000，“B”是 000001，“C”是 000010 等），并抓取 8 位组以制作解码后的字节 输入。从 base64 编码数据的前 340 个字符，我们得到 原始数据的前 255 个字节（签名字节）。这 给我们留下了 12 位。我们抓取 8 位来形成第 256 个字节 原始输入，并且由于不再有足够的位来形成 一个完整的字节，我们只丢弃最后 4 位（记住这四个 是我们在编码时“填充”的 0）。
由于最后 4 位被简单地丢弃（它们不构成 编码的签名，它们只是用于填充），这 4 位 实际上可以是任何东西。只有最后 6 位中的前两位 实际上是原始消息的一部分。
这真的很难用文字解释，但如果你 自己尝试一下：只需手动将单个字节编码为 Base64， 然后解码。
举个例子，如果最后一个 base64 字符是“A”，这就是 base64 索引为 0 (000000)。字符“B”到“P”对应 到 eh base64 索引 1 (000001) 到 15 (001111)。在所有的 这些，前两位总是 00。因为最后四位（是 将被丢弃），你可以选择从 A 到 P 的任何东西，然后你 不会对实际重要的两个位产生任何影响。如果你走的话 到“Q”，索引为 16 (010000)，现在您已经更改了这两个中的一个 消息中的位，并且签名不再有效。
【讨论】：