英文:

Base-64 Exception When Decoding id_token_hint Claims in Custom Policy

问题

我正在根据B2C Samples Github中链接的此电子邮件邀请示例来适应我的需求，该示例在定义ID令牌提示技术配置文件文档中有链接。我对策略本身没有进行实质性的更改，只是添加了一个令牌受众验证参数。但是，我已经将令牌签发者适应为从Azure Key Vault检索其证书。

生成的令牌包含签名，这些签名在jwt.io（包括示例令牌验证）使用令牌签发者的已发布元数据，因此我至少相对自信签名令牌是有效的。然而，我收到了一个奇怪的异常，来自处理ID令牌提示的GetClaims编排步骤：

输入不是有效的Base-64字符串，因为它包含一个非Base 64字符，超过两个填充字符，或填充字符之间的非法字符。

消息本身有点令人担忧，因为在此交换中，所有内容都是Base64Url编码的，而在该编码方法中没有填充字符。这似乎发生在任何令牌声明验证之前，因为我故意在我的技术配置文件的<Item Key="IdTokenAudience" />元素中放置了不正确的值，以查看处理过程进行到何种程度。

从Application Insights的事件输出中，以下是最后几个位输出部分：

{
  "Kind": "Transition",
  "Content": {
    "EventName": "GetClaims",
    "StateName": "AwaitingNextStep"
  }
},
{
  "Kind": "Predicate",
  "Content": "Web.TPEngine.StateMachineHandlers.NoOpHandler"
},
{
  "Kind": "HandlerResult",
  "Content": {
    "Result": true,
    "Statebag": {
      "MACHSTATE": {
        "c": "2023-07-17T14:46:56.4499692Z",
        "k": "MACHSTATE",
        "v": "AwaitingNextStep",
        "p": true
      }
    },
    "PredicateResult": "True"
  }
},
{
  "Kind": "Action",
  "Content": "Web.TPEngine.StateMachineHandlers.GetRelyingPartyInputClaimsHandler"
},
{
  "

<details>
<summary>英文:</summary>

I am adapting [this email invite sample](https://github.com/azure-ad-b2c/samples/blob/master/policies/invite/README.md) from the B2C Samples Github linked in the [define an ID token hint technical profile](https://learn.microsoft.com/en-us/azure/active-directory-b2c/id-token-hint) documentation for my purposes. I haven&#39;t made substantive changes to the policy itself, other than to add a token audience validation parameter. I have however adapted the token issuer to retrieve its certificate from Azure Key Vault.

The tokens generated contain signatures that are validating against [jwt.io](https://jwt.io/#debugger-io?token=eyJhbGciOiJSUzI1NiIsImtpZCI6IkI1NkFCNjI1RjE5NjBCQzk5NTZDNzhDMDVENTMzQjlDOEE1M0UzMUYiLCJ4NXQiOiJ0V3EySmZHV0M4bVZiSGpBWFZNN25JcFQ0eDgiLCJ0eXAiOiJKV1QifQ.eyJuYW1lIjoiQm9iIFN1cnVuY2xlIiwiZW1haWwiOiJzcG9vZmVkLmluYm94QGdtYWlsLmNvbSIsInBob25lIjoiNTU1ODY3NTMwOSIsIm5iZiI6MTY4OTYxMTExNiwiZXhwIjoxNjg5Njk3NTE2LCJpc3MiOiJodHRwczovL2xzbHNjdWIyY2FwcC5henVyZXdlYnNpdGVzLm5ldC8iLCJhdWQiOiJodHRwczovL2xzbGVhcm5iMmMuYjJjbG9naW4uY29tLyJ9.YQcTE4aAkMzs7_JHM-UJJHlfxSHzk0OnnzPB4vzHo4Of1In3v_lni9x7TpVTJQAq8lu33aygy9EwQyqY4L9eLNy4JVEXVFfMltd2jd4JZjxAHLqr4Ngb5EeuMM67ST_87MuBzWY4EKXR1X4ZJU8zsZv6_OCL57ycGzYr5FjEOd_Mojle8Pc3XjNYmRGTZqxt7LYqw-V0h6yjJoem0ui_9JodHMZr597leUN9Ki4oLPP-GUDpzw-n1F90dA1Rra1dZYTNFfUyGXolTmcSCSMWhC0BX_HSGu1kvGj_9aez1FyQuAlwTNMaG4dxPWii54lCzf77G6maMMA0c_IJDtHTHw&amp;publicKey=%7B%0A%20%20%22e%22%3A%20%22AQAB%22%2C%0A%20%20%22kty%22%3A%20%22RSA%22%2C%0A%20%20%22n%22%3A%20%22sWUc8rBzx3u24caS15q7L8c-TFEQXVHufV2jwkdJGA_5s660PciYEQA-yuSlaXqln610AKbg1gdMLpUP_wQkAj5kmLltwJJww0TXovYi5pOqQJKru4QoFGiHWeyStC2_cokubRkW2RIvxK87nGcJVgP1JaYn1vGW9riYNLJg1pOTOPTRoiV7FPArtFt83Dr2iPN3sR2LTjDYFuUiGPpZwpQCqMV-gSeTRnqH6n0rUaVpmv8yOCpnwZ1JfLrHQkpRwsIxLo2MsfA0li3qOnb_I8k2iGjiGcImvW-qP5SskIMCl_NwPOE_xEMOBQdDSxqajRh7x2tmv1aWDonrUT1yUQ%22%0A%7D) (sample token validation included) using the [published metadata](https://lslscub2capp.azurewebsites.net/.well-known/openid-configuration) from the token issuer, so I&#39;m at least relatively confident that the signed tokens are valid. However, I&#39;m receiving an odd exception from the GetClaims orchestration step that processes the ID token hint:

&gt;The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.

The message itself is somewhat concerning as everything in this exchange is Base64Url encoded and there are no padding characters in that encoding method. This appears to happen before any sort of token claim validation as I purposefully placed an incorrect value in the `&lt;Item Key=&quot;IdTokenAudience&quot; /&gt;` element of my technical profile to see how far the process got.

The last few bits of event output from Application Insights is reproduced below:

{
"Kind": "Transition",
"Content": {
"EventName": "GetClaims",
"StateName": "AwaitingNextStep"
}
},
{
"Kind": "Predicate",
"Content": "Web.TPEngine.StateMachineHandlers.NoOpHandler"
},
{
"Kind": "HandlerResult",
"Content": {
"Result": true,
"Statebag": {
"MACHSTATE": {
"c": "2023-07-17T14:46:56.4499692Z",
"k": "MACHSTATE",
"v": "AwaitingNextStep",
"p": true
}
},
"PredicateResult": "True"
}
},
{
"Kind": "Action",
"Content": "Web.TPEngine.StateMachineHandlers.GetRelyingPartyInputClaimsHandler"
},
{
"Kind": "FatalException",
"Content": {
"Time": "2:46 PM",
"Exception": {
"Kind": "Handled",
"HResult": "80131537",
"Message": "The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters. ",
"Data": {}
}
}
}

The technical profile hasn't been updated drastically from the sample other than to change the metadata endpoint and provide a token audience:

<ClaimsProvider>
<DisplayName>My ID Token Hint ClaimsProvider</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="IdTokenHint_ExtractClaims">
<DisplayName> My ID Token Hint TechnicalProfile</DisplayName>
<Protocol Name="None" />
<Metadata>

    <!--Sample action required: replace with your endpoint location -->
<Item Key="METADATA">https://lslscub2capp.azurewebsites.net/.well-known/openid-configuration</Item>
<Item Key="IdTokenAudience">https://lslearnb2c.b2clogin.com/</Item>
<!-- <Item Key="issuer">your_optional_token_issuer_override</Item> -->
</Metadata>
<OutputClaims>
<!--Sample: Read the email cliam from the id_token_hint-->
<OutputClaim ClaimTypeReferenceId="email" />  
</OutputClaims>
</TechnicalProfile>

</TechnicalProfiles>
</ClaimsProvider>

</details>
# 答案1
**得分**: 0
这是因为错误地使用了 base64url 编码而不是 RFC 所需的指定 base64 编码来对 JWKS 文档的 `x5c` 元素进行编码而导致的结果。【请注意 GitHub Copilot 过于热心。】
<details>
<summary>英文:</summary>
This turned out to be a result of mistakenly encoding the `x5c` element of the JWKS document using base64url encoding rather than the [specified base64 encoding](https://datatracker.ietf.org/doc/html/rfc7517#section-4.7) required by the RFC.
(Beware the overly-helpful GitHub Copilot.)
</details>