azure - Azure AD 身份验证中的访问 token 验证

Question

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

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

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

Answer 1

有趣的是，我们在安全审核中也遇到了这个问题。

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

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

This is a side effect of base64 decoding, the fact that the decoded signature is 256 bytes long, and the fact that 256 leaves a remained of 1 when divided by 3. 😊

The RS256 alg value corresponds to the “RSASSA-PKCS1-v1_5 using SHA-256” algorithm, which results in a signature which is 256 bytes long that is then base64url-encoded to when constructing the JWT, resulting in 342 characters after the second ‘.’. The first 255 bytes of the unencoded signature all “fit” nicely into 340 characters in base64 (every 6 bits of input result in 1 encoded character). From the last byte of the signature, the first 6 bits give the 341st character of the encoded signature. Now we have just two bits left to encode. Since we need 6 bits to obtain a base64-coded character, we append four 0s giving us 6 bits, and encode as normal.

When decoding, we start from the left, convert each character to its base64 index in binary (e.g. “A” is 000000, “B” is 000001, “C” is 000010, etc.), and grab groups of 8 bits to make a byte of the decoded input. From the first 340 characters of base64-encoded data, we get the first 255 bytes of the original data (the signature bytes). This leaves us with 12 bits still. We grab 8 bits to form the 256th byte of the original input, and since there are no longer enough bits to form a full byte, we just discard the last 4 bits (remember that these four were the 0s we “filled in” when encoding).

Since the last 4 bits are simply discarded (they don’t form part of the encoded signature, they’re just there for padding), these 4 bits can actually be anything at all. Only the first two of the last 6 bits are actually part of the original message.

This is really hard to explain in text, but it’s really obvious if you try it out for yourself: Just encode a single byte to Base64 manually, then decode it.

To take your example, if the last base64 character is “A”, this is the base64 index is 0 (000000). The characters “B” through “P “ correspond to eh the base64 indexes 1 (000001) through 15 (001111). In all of these, the first two bits are always 00. Since the last four (are going to be discarded), you can choose anything from A to P, and you won’t have any effect on the two bits that actually matter. If you go to “Q”, with index 16 (010000), now you’ve changed one of those two bits from the message, and the signature is no longer valid.