在Azure AD身份验证中访问令牌验证

Question

我能够在Azure AD身份验证中请求令牌。但是问题是，每当我更改access_token中的最后一个字符时，它仍会在我的API中成功请求。我只是遵循这个https://mehmetkut.com/2017/05/protect-aspnetcore-webapi-resources-with-azure-active-directory-en/有没有一种方法可以验证令牌？仅当我至少更改了最后一个字符中的一个时，才会发生这种情况。

https://mehmetkut.com/2017/05/protect-aspnetcore-webapi-resources-with-azure-active-directory-zh/

即使我更改了最后一个字符，令牌仍然有效。

Answer 1

有趣的是，我们在安全审核中也做到了这一点。

事实证明，签名的最后4位只是填充而已，并不是签名的一部分。因此某些字符将被接受为最后一个字符，而不是全部。在这种情况下，您实际上并没有修改签名数据，仅是填充。

这是比我聪明的人的解释：

这是base64解码的副作用，这是解码签名长256个字节的事实，以及256除以3后剩下的1的事实。

RS256 alg值对应于“使用SHA-256的RSASSA-PKCS1-v1_5”算法，该算法产生一个256字节长的签名，然后在构造JWT时对其进行base64url编码，第二个' 。'。未编码签名的前255个字节都很好地“适合”了base64中的340个字符（每6位输入产生1个编码字符）。从签名的最后一个字节开始，前6位给出编码签名的第341个字符。现在我们只剩下两位要编码。由于我们需要6位来获得base64编码的字符，因此我们附加了四个0给出了6位，然后按常规进行编码。

解码时，我们从左侧开始，将每个字符转换为二进制形式的base64索引（例如“ A”为000000，“ B”为000001，“ C”为000010，依此类推），然后抓取8位的组解码输入的字节。从base64编码数据的前340个字符中，我们获得原始数据的前255个字节（签名字节）。剩下的还有12位。我们抓取8位以形成原始输入的第256个字节，并且由于不再有足够的位形成完整的字节，我们只丢弃了最后4位（请记住，这4位是我们在编码时“填充”的0） ）。

由于仅丢弃了最后4位（它们不构成编码签名的一部分，因此仅用于填充），因此这4位实际上可以是任何东西。最后6位中只有前两位实际上是原始消息的一部分。

这确实很难用文字解释，但是如果您亲自尝试一下，则很明显：只需手动将单个字节编码为Base64，然后对其进行解码。

以您的示例为例，如果最后一个base64字符为“ A”，则这是base64索引为0（000000）。字符“ B”至“ P”对应于base64索引1（000001）至15（001111）。在所有这些中，前两位始终为00。由于后四位（将被丢弃），您可以选择从A到P的任何内容，并且不会对实际上重要的两位产生任何影响。如果转到索引为16（010000）的“ Q”，那么现在您已更改了消息中的这两位，而签名不再有效。