json怎么表述指纹_符合标准的json网络签名儿童和指纹

json怎么表述指纹

In this article, we are going to explore the world of JSON web signatures (JWS), focusing specifically on how third parties can access and identify your keys in order to verify your signatures.

在本文中，我们将探索JSON Web签名 (JWS)的世界，特别关注第三方如何访问和识别您的密钥以验证您的签名。

In a follow up article, we’ll look at a practical standards based approach using the ForgeRock Identity Platform.

在后续文章中 ，我们将研究使用ForgeRock Identity Platform的基于标准的实用方法。

术语 (Terminology)

As a starting point, let’s look at a sample authentication token which uses the OpenID Connect standard (OIDC) to identify an end user.

首先，让我们看一个示例身份验证令牌，该令牌使用OpenID Connect标准 (OIDC)标识最终用户。

原始OIDC令牌 (Raw OIDC token)

eyJ0eXAiOiJKV1QiLCJraWQiOiJFRjcxaVNhb3NiQzVDNHRDNlN5cTFHbTY0N00iLCJhbGciOiJQUzI1NiJ9.eyJhdF9oYXNoIjoibEVqbFlqWVgtYTF6djl1VktsODlWUSIsInN1YiI6ImphbmUuZG9lIiwiYXVkaXRUcmFja2luZ0lkIjoiY2IxNThlYjgtOGM4Zi00MGI1LWE0MGUtYTU0NjQyOTI1ZTJhLTI1MiIsImlzcyI6Imh0dHBzOi8vYW0uYXV0aGRlbW8ub3JnL29hdXRoMi9yZWFsbXMvcm9vdC9yZWFsbXMvdGVzdCIsInRva2VuTmFtZSI6ImlkX3Rva2VuIiwiYXVkIjoidGVzdGNsaWVudCIsImF6cCI6InRlc3RjbGllbnQiLCJhdXRoX3RpbWUiOjE1OTgyODg4OTAsInJlYWxtIjoiL3Rlc3QiLCJleHAiOjE1OTgyODk0OTMsInRva2VuVHlwZSI6IkpXVFRva2VuIiwiaWF0IjoxNTk4Mjg4ODkzfQ.NNKNdsOD2h0Y1kz75Ljqluu3QWzgVZyqrOxmBnMI9I6nPAqhd4rkxo3HsQ_E1e_0dpa_jp-xB4-FXk0RLI2xqFp7fEehW9NdaMZm2nT75Id2O_IAoNhqV_iski6HlKSwB3qJ5MwjBS2R2EG_3Co3KDn2NuyIuqpu1RS6Ut1TnYH8P4-jse4AIIRr9kM-Id52-TU1NlKkSAcHvjqyoPhXt6L_6nA60ZtduXWVwkWCuvhH32myG5K8UEQxNU-lfO8L7VAWQPRPDPo1fDqlyMKeWQHlGA8TrgXRbdry1p0JvETFFXE_GlxkOO5MFeOB3HgwftW6Mhf-N9g3Wewx3HMhgQ

In JWx terms, this is a JSON Web Token (JWT) secured by a JSON Web Signature (JWS).

用JW x术语来说，这是受JSON Web签名 (JWS)保护的JSON Web令牌 (JWT)。

The token consists of three elements, which are each base64url encoded and then concatenated with dot delimiters. If we break down the three elements of our token and decode them, we get the following:

令牌由三个元素组成，每个元素都经过base64url编码，然后与点定界符连接在一起。 如果我们分解令牌的三个元素并对其进行解码，则会得到以下结果：

• The JSON Object Signing and Encryption (JOSE) header. More on this later.

  JSON对象签名和加密(JOSE)标头 。 稍后再详细介绍。

{
  "typ": "JWT",
  "kid": "EF71iSaosbC5C4tC6Syq1Gm647M",
  "alg": "PS256"
}

• The JOSE payload (i.e. the signed data). In the case of OIDC, this contains details about the identity we have authenticated.

  JOSE有效负载 ( 即已签名的数据)。 对于OIDC，它包含有关我们已认证身份的详细信息。

{
  "at_hash": "lEjlYjYX-a1zv9uVKl89VQ",
  "sub": "jane.doe",
  "auditTrackingId": "cb158eb8-8c8f-40b5-a40e-a54642925e2a-252",
  "iss": "https://am.authdemo.org/oauth2/realms/root/realms/test",
  "tokenName": "id_token",
  "aud": "testclient",
  "azp": "testclient",
  "auth_time": 1598288890,
  "realm": "/test",
  "exp": 1598289493,
  "tokenType": "JWTToken",
  "iat": 1598288893
}

• The JOSE signature computed across the header and payload (binary value when decoded, so not shown here).

  跨越标头和有效负载计算的JOSE签名 (解码时为二进制值，因此此处未显示)。

The method required to verify the signature depends on the method used to create it. There are two broad types of key used for signature: symmetric and asymmetric.

验证签名所需的方法取决于创建签名的方法。 有两种用于签名的密钥： 对称密钥和非 对称密钥。

Symmetric key based signatures use a shared key. You need a copy of the signing key in order to verify the signature. In this case, you need a secure way of sharing the signing key between parties, and you need to trust each party you share the key with.

基于对称密钥的签名使用共享密钥。 您需要签名密钥的副本才能验证签名。 在这种情况下，您需要一种在各方之间共享签名密钥的安全方法，并且需要信任与之共享密钥的每一方。

Asymmetric key based signatures use a private/public key pair. In this case you only need the public key to verify the signature. Since the public key is not sensitive (i.e. you can’t use it to forge signatures), you can freely publish the key to allow anyone to verify your signatures.

基于非对称密钥的签名使用私钥/公钥对。 在这种情况下，您只需要公共密钥即可验证签名。 由于公共密钥不敏感(即您不能使用它来伪造签名)，因此您可以自由地发布密钥，以允许任何人验证您的签名。

We are going to focus on asymmetric keys, because they offer the best security and most flexible deployment options.

我们将重点放在非对称密钥上，因为它们提供了最佳的安全性和最灵活的部署选项。

共享钥匙 (Sharing your keys)

In order for relying parties to be able to verify your signatures, they need access to your keys. So how do you give them this access?

为了使依赖方能够验证您的签名，他们需要访问您的密钥。 那么，您如何授予他们这种访问权限？

Firstly, you need a common way to represent your keys. One method is to use the JSON Web Key (JWK) standard. This is a JSON representation of keys used for signing, encryption, and various other purposes. The following is an example JWK with a couple of signing keys — one RSA key and one Elliptic Curve.

首先，您需要一种通用的方式来表示您的密钥。 一种方法是使用JSON Web密钥 (JWK)标准。 这是用于签名，加密和各种其他目的的密钥的JSON表示。 以下是带有几个签名密钥的一个JWK示例-一个RSA密钥和一个椭圆曲线。

JWK样本文件 (Sample JWK document)

{
 “keys”: [
 {
 “kty”: “RSA”,
 “kid”: “EF71iSaosbC5C4tC6Syq1Gm647M”,
 “use”: “sig”,
 “x5t”: “5eOfy1Nn2MMIKVRRkq0OgFAw348”,
 “x5c”: [
“MIIDdzCCAl+gAwIBAgIES3eb+zANBgkqhkiG9w0BAQsFADBsMRAwDgYDVQQGEwdVbmtub3duMRAwDgYDVQQIEwdVbmtub3duMRAwDgYDVQQHEwdVbmtub3duMRAwDgYDVQQKEwdVbmtub3duMRAwDgYDVQQLEwdVbmtub3duMRAwDgYDVQQDEwdVbmtub3duMB4XDTE2MDUyNDEzNDEzN1oXDTI2MDUyMjEzNDEzN1owbDEQMA4GA1UEBhMHVW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4GA1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjEQMA4GA1UEAxMHVW5rbm93bjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANdIhkOZeSHagT9ZecG+QQwWaUsi7OMv1JvpBr/7HtAZEZMDGWrxg/zao6vMd/nyjSOOZ1OxOwjgIfII5+iwl37oOexEH4tIDoCoToVXC5iqiBFz5qnmoLzJ3bF1iMupPFjz8Ac0pDeTwyygVyhv19QcFbzhPdu+p68epSatwoDW5ohIoaLzbf+oOaQsYkmqyJNrmht091XuoVCazNFt+UJqqzTPay95Wj4F7Qrs+LCSTd6xp0Kv9uWG1GsFvS9TE1W6isVosjeVm16FlIPLaNQ4aEJ18w8piDIRWuOTUy4cbXR/Qg6a11l1gWls6PJiBXrOciOACVuGUoNTzztlCUkCAwEAAaMhMB8wHQYDVR0OBBYEFMm4/1hF4WEPYS5gMXRmmH0gs6XjMA0GCSqGSIb3DQEBCwUAA4IBAQDVH/Md9lCQWxbSbie5lPdPLB72F4831glHlaqms7kzAM6IhRjXmd0QTYq3Ey1J88KSDf8A0HUZefhudnFaHmtxFv0SF5VdMUY14bJ9UsxJ5f4oP4CVh57fHK0w+EaKGGIw6TQEkL5L/+5QZZAywKgPz67A3o+uk45aKpF3GaNWjGRWEPqcGkyQ0sIC2o7FUTV+MV1KHDRuBgreRCEpqMoY5XGXe/IJc1EJLFDnsjIOQU1rrUzfM+WP/DigEQTPpkKWHJpouP+LLrGRj2ziYVbBDveP8KtHvLFsnexA/TidjOOxChKSLT9LYFyQqsvUyCagBb4aLs009kbW6inN8zA6”
 ],
 “n”: “10iGQ5l5IdqBP1l5wb5BDBZpSyLs4y_Um-kGv_se0BkRkwMZavGD_Nqjq8x3-fKNI45nU7E7COAh8gjn6LCXfug57EQfi0gOgKhOhVcLmKqIEXPmqeagvMndsXWIy6k8WPPwBzSkN5PDLKBXKG_X1BwVvOE9276nrx6lJq3CgNbmiEihovNt_6g5pCxiSarIk2uaG3T3Ve6hUJrM0W35QmqrNM9rL3laPgXtCuz4sJJN3rGnQq_25YbUawW9L1MTVbqKxWiyN5WbXoWUg8to1DhoQnXzDymIMhFa45NTLhxtdH9CDprXWXWBaWzo8mIFes5yI4AJW4ZSg1PPO2UJSQ”,
 “e”: “AQAB”,
 “alg”: “PS256”
 },
 {
 “kty”: “EC”,
 “kid”: “WhUPrWNhvLWLxtrU3–1KMKn2o8I”,
 “use”: “sig”,
 “x5t”: “MUOPc5byMEN9q_9gqArkd1EDajg”,
 “x5c”: [
“MIIBwjCCAWkCCQCw3GyPBTSiGzAJBgcqhkjOPQQBMGoxCzAJBgNVBAYTAlVLMRAwDgYDVQQIEwdCcmlzdG9sMRAwDgYDVQQHEwdCcmlzdG9sMRIwEAYDVQQKEwlGb3JnZVJvY2sxDzANBgNVBAsTBk9wZW5BTTESMBAGA1UEAxMJZXMyNTZ0ZXN0MB4XDTE3MDIwMzA5MzQ0NloXDTIwMTAzMDA5MzQ0NlowajELMAkGA1UEBhMCVUsxEDAOBgNVBAgTB0JyaXN0b2wxEDAOBgNVBAcTB0JyaXN0b2wxEjAQBgNVBAoTCUZvcmdlUm9jazEPMA0GA1UECxMGT3BlbkFNMRIwEAYDVQQDEwllczI1NnRlc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ3sy05tV/3YUlPBi9jZm9NVPeuBmntrtcO3NP/1HDsgLsTZsqKHD6KWIeJNRQnONcriWVaIcZYTKNykyCVUz93MAkGByqGSM49BAEDSAAwRQIgZhTox7WpCb9krZMyHfgCzHwfu0FVqaJsO2Nl2ArhCX0CIQC5GgWD5jjCRlIWSEFSDo4DZgoQFXaQkJUSUbJZYpi9dA==”
 ],
 “x”: “N7MtObVf92FJTwYvY2ZvTVT3rgZp7a7XDtzT_9Rw7IA”,
 “y”: “uxNmyoocPopYh4k1FCc41yuJZVohxlhMo3KTIJVTP3c”,
 “crv”: “P-256”,
 “alg”: “ES256”
 }
 ]
}}}

Secondly, you need a common way to communicate this key information. One option is to publish your JWK online through HTTPS, via a known JWK URI. This allows dynamic changes such as algorithm updates and key rollover, and makes relying party configuration very simple. A common way to advertise your JWK URI is via your OpenID Connect Discovery endpoint.

其次，您需要一种通用的方式来传达此关键信息。 一种选择是通过HTTPS通过已知的JWK URI在线发布JWK。 这允许动态更改，例如算法更新和密钥翻转，并使依赖方的配置非常简单。 宣传JWK URI的常用方法是通过OpenID Connect Discovery端点。

关键标识符 (Key Identifiers)

You’ll see from the sample JWK document above that a JWK can include multiple keys, covering different key generations, purposes and algorithms. When verifying the signature on a JWS, there needs to be a way to identify the required key within a JWK.

您将从上面的样本JWK文档中看到，JWK可以包括多个密钥，涵盖了不同的密钥生成，用途和算法。 在JWS上验证签名时，需要一种在JWK中标识所需密钥的方法。

Step forward the Key Identifier (KID). The JWS can include a signing KID in the"kid"header field, which must match a "kid" entry in your JWK. Revisiting our sample OIDC token, we can see the "kid" parameter in the JOSE header

前进密钥标识符(KID) 。 JWS可以在"kid"标头字段中包含一个签名KID，该签名KID必须与您的JWK中的"kid"条目匹配。 再次访问示例OIDC令牌，我们可以在JOSE标头中看到"kid"参数

OIDC令牌头 (OIDC token header)

{
  "typ": "JWT","kid": "EF71iSaosbC5C4tC6Syq1Gm647M",
  "alg": "PS256"
}

Looking at the key entries in the sample JWK, we can find a matching entry with the same "kid" parameter as follows

查看示例JWK中的关键条目，我们可以找到具有相同"kid"参数的匹配条目，如下所示

JWK密钥输入 (JWK key entry)

{
 “kty”: “RSA”,“kid”: “EF71iSaosbC5C4tC6Syq1Gm647M”,
 “use”: “sig”,
 “x5t”: “5eOfy1Nn2MMIKVRRkq0OgFAw348”,
 “x5c”: [
“MIIDdzCC...kbW6inN8zA6”
 ],
 “n”: “10iGQ5l5Idq...zDymIMhFa45NTLhxtdH9CDprXWXWBaWzo8mIFes5yI4AJW4ZSg1PPO2UJSQ”,
 “e”: “AQAB”,
 “alg”: “PS256”
 }

We can now extract the public key from this JWK entry and use it to verify the signature on our OIDC token.

现在，我们可以从此JWK条目中提取公钥，并使用它来验证OIDC令牌上的签名。

尝试一下 (Trying it out)

We can use openssl to test the end to end process for signature verification. Of course this would normally be performed automatically by the relying party platform.

我们可以使用openssl来测试端到端的签名验证过程。 当然，这通常将由依赖方平台自动执行。

For a scripted approach, have a look at the sample jwtx script available here.

对于脚本化方法，请查看此处提供的样本jwtx脚本。

The steps (using the bash shell on *nix) are as follows

步骤(在* nix上使用bash shell)如下

• Load up the OIDC token
  加载OIDC令牌

oidc_token='eyJ0eXAiOiJKV1QiLCJraWQiOiJFRjcxaVNhb3NiQzVDNHRDNlN5cTFHbTY0N00iLCJhbGciOiJQUzI1NiJ9.eyJhdF9oYXNoIjoibEVqbFlqWVgtYTF6djl1VktsODlWUSIsInN1YiI6ImphbmUuZG9lIiwiYXVkaXRUcmFja2luZ0lkIjoiY2IxNThlYjgtOGM4Zi00MGI1LWE0MGUtYTU0NjQyOTI1ZTJhLTI1MiIsImlzcyI6Imh0dHBzOi8vYW0uYXV0aGRlbW8ub3JnL29hdXRoMi9yZWFsbXMvcm9vdC9yZWFsbXMvdGVzdCIsInRva2VuTmFtZSI6ImlkX3Rva2VuIiwiYXVkIjoidGVzdGNsaWVudCIsImF6cCI6InRlc3RjbGllbnQiLCJhdXRoX3RpbWUiOjE1OTgyODg4OTAsInJlYWxtIjoiL3Rlc3QiLCJleHAiOjE1OTgyODk0OTMsInRva2VuVHlwZSI6IkpXVFRva2VuIiwiaWF0IjoxNTk4Mjg4ODkzfQ.NNKNdsOD2h0Y1kz75Ljqluu3QWzgVZyqrOxmBnMI9I6nPAqhd4rkxo3HsQ_E1e_0dpa_jp-xB4-FXk0RLI2xqFp7fEehW9NdaMZm2nT75Id2O_IAoNhqV_iski6HlKSwB3qJ5MwjBS2R2EG_3Co3KDn2NuyIuqpu1RS6Ut1TnYH8P4-jse4AIIRr9kM-Id52-TU1NlKkSAcHvjqyoPhXt6L_6nA60ZtduXWVwkWCuvhH32myG5K8UEQxNU-lfO8L7VAWQPRPDPo1fDqlyMKeWQHlGA8TrgXRbdry1p0JvETFFXE_GlxkOO5MFeOB3HgwftW6Mhf-N9g3Wewx3HMhgQ'

• Extract the OIDC token header and payload (i.e. the first two elements of the token) as the input data for signature verification. Be careful not to add a newline.
  提取OIDC令牌头和有效负载(即令牌的前两个元素)作为输入数据以进行签名验证。 注意不要添加换行符。

awk -F. '{printf("%s.%s",$1,$2)}' <<< "$oidc_token" > signed.data

• Extract the OIDC token signature (i.e the third element of the token) and convert to binary (openssl doesn’t support base64url decoding, so we have to do a bit of manipulation with sed to convert it to plain base64)

  提取OIDC令牌签名(即令牌的第三个元素)并转换为二进制( openssl不支持base64url解码，因此我们必须对sed进行一些操作才能将其转换为纯base64)

awk -F. '{printf($3)}' <<< "$oidc_token" | sed 's/-/+/g; s/_/\//g; s/$/==/' | openssl base64 -d -A -out signature.bin

• Search the JWK document for the KID from the token header, and extract the public key from the corresponding certificate (the "x5c" parameter in the JWK). The certificate will be all on one line, so we need to feed it through openssl twice.

  从令牌头中搜索JWK文档以获取KID，然后从相应的证书( "x5c"的"x5c"参数)中提取公钥。 证书将全部放在一行上，因此我们需要两次将其通过openssl馈入。

echo 'MIIDdzCCAl+gAwIBAgIES3eb+zANBgkqhkiG9w0BAQsFADBsMRAwDgYDVQQGEwdVbmtub3duMRAwDgYDVQQIEwdVbmtub3duMRAwDgYDVQQHEwdVbmtub3duMRAwDgYDVQQKEwdVbmtub3duMRAwDgYDVQQLEwdVbmtub3duMRAwDgYDVQQDEwdVbmtub3duMB4XDTE2MDUyNDEzNDEzN1oXDTI2MDUyMjEzNDEzN1owbDEQMA4GA1UEBhMHVW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4GA1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjEQMA4GA1UEAxMHVW5rbm93bjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANdIhkOZeSHagT9ZecG+QQwWaUsi7OMv1JvpBr/7HtAZEZMDGWrxg/zao6vMd/nyjSOOZ1OxOwjgIfII5+iwl37oOexEH4tIDoCoToVXC5iqiBFz5qnmoLzJ3bF1iMupPFjz8Ac0pDeTwyygVyhv19QcFbzhPdu+p68epSatwoDW5ohIoaLzbf+oOaQsYkmqyJNrmht091XuoVCazNFt+UJqqzTPay95Wj4F7Qrs+LCSTd6xp0Kv9uWG1GsFvS9TE1W6isVosjeVm16FlIPLaNQ4aEJ18w8piDIRWuOTUy4cbXR/Qg6a11l1gWls6PJiBXrOciOACVuGUoNTzztlCUkCAwEAAaMhMB8wHQYDVR0OBBYEFMm4/1hF4WEPYS5gMXRmmH0gs6XjMA0GCSqGSIb3DQEBCwUAA4IBAQDVH/Md9lCQWxbSbie5lPdPLB72F4831glHlaqms7kzAM6IhRjXmd0QTYq3Ey1J88KSDf8A0HUZefhudnFaHmtxFv0SF5VdMUY14bJ9UsxJ5f4oP4CVh57fHK0w+EaKGGIw6TQEkL5L/+5QZZAywKgPz67A3o+uk45aKpF3GaNWjGRWEPqcGkyQ0sIC2o7FUTV+MV1KHDRuBgreRCEpqMoY5XGXe/IJc1EJLFDnsjIOQU1rrUzfM+WP/DigEQTPpkKWHJpouP+LLrGRj2ziYVbBDveP8KtHvLFsnexA/TidjOOxChKSLT9LYFyQqsvUyCagBb4aLs009kbW6inN8zA6' | openssl base64 -d -A | openssl x509 -inform der -noout -pubkey > pubkey.pem

• Finally, verify the signature. Our sample token is signed with the PS256 algorithm, so we need to tell openssl about the padding mode (PSS) and hashing algorithm (SHA256)

  最后，验证签名。 我们的示例令牌是使用PS256算法签名的，因此我们需要告诉openssl有关填充模式( PSS )和哈希算法( SHA256 )

openssl dgst -sigopt rsa_padding_mode:pss -verify pubkey.pem -sha256 -signature signature.bin signed.data

All being well, openssl will output the following message:

一切都很好， openssl将输出以下消息：

Verified OK

There are various niceties around using openssl for JWS verification — the jwtx script has more examples.

使用openssl进行JWS验证有很多好处-jwtx脚本有更多示例。

基于标准的密钥标识符 (Standards Based Key Identifiers)

Key Identifiers can be any arbitrary value, as long as they are unique within the JWK.

密钥标识符可以是任意值，只要它们在JWK中是唯一的即可。

So — if you can use any unique string for your Key Identifier, why would you want to use a standards based algorithm for creating a KID? Why not just use your own method of deriving key IDs, or even just a vanilla UUID?

因此，如果您可以将任何唯一的字符串用作密钥标识符，那么为什么要使用基于标准的算法来创建KID？ 为什么不仅仅使用您自己的方法来获取密钥ID，或者甚至只是使用普通的UUID？

Well, for one thing, following a known standard ensures that you are using robust, collision-resistant identifiers. Also, and perhaps more crucially, it means that you can agree on a common standard with third parties in cases where you need a consistent approach to Key IDs.

好吧，一方面，遵循已知标准可确保您使用的是可靠的，抗碰撞的标识符。 而且，也许更关键的是，这意味着在需要一致的密钥ID方式的情况下，您可以与第三方达成共同的标准。

For example, in the case of the UK Open Banking ecosystem, your signing keys are published on your behalf by the Open Banking Directory. The Directory creates and publishes your JWK via a central trusted location. The Key Identifiers used within the JWK are created by the Directory, using the algorithm specified by the RFC 7638 standard.

例如，对于UK Open Banking生态系统，您的签名密钥由Open Banking Directory代表您发布。 该目录通过中央信任位置创建和发布您的JWK。 JWK中使用的密钥标识符是由Directory使用RFC 7638标准指定的算法创建的。

As an Open Banking participant, when you construct a JWS such as an OIDC token, you need to make sure that the KID in your token header matches the KID in the JWK published by the Directory. Otherwise, the relying party will not be able to find the public key required to verify your signature. The smartest way to ensure your tokens contain the right KIDs is to use the same algorithm as the Directory.

作为开放银行参与者，在构造OWS令牌之类的JWS时，需要确保令牌头中的KID与目录发布的JWK中的KID相匹配。 否则，依赖方将无法找到验证您的签名所需的公钥。 确保令牌包含正确的KID的最明智的方法是使用与目录相同的算法。

RFC 7638算法 (The RFC 7638 Algorithm)

Let’s have a look at the RFC 7638 algorithm, in order to understand the requirements for its implementation.

让我们看一下RFC 7638算法，以了解其实现的要求。

According to the standard, each KID is a “JWK Thumbprint”, based on the details of the key from the JWK. This thumbprint is essentially a hash of a specific subset of JWK fields. The exact subset of fields depends on the key type (Elliptic Curve, RSA or symmetric).

根据该标准，每个KID都是基于JWK密钥的详细信息的“ JWK指纹” 。 此指纹实际上是JWK字段的特定子集的哈希。 字段的确切子集取决于密钥类型(椭圆曲线，RSA或对称)。

Taking our sample JWK as a working example, we can look at how to build a KID for the key used to sign our OIDC token.

以我们的示例JWK作为工作示例，我们可以看看如何为用于签名OIDC令牌的密钥构建KID。

First, we extract the JWK entry for the OIDC signing key. Then we remove all of the parameters except the "e", "kty" and "n" parameters (this is the specified subset for an RSA key). We then put them in alphabetical order, ending up with the following:

首先，我们提取OIDC签名密钥的JWK条目。 然后，我们删除除"e" ， "kty"和"n"参数(这是RSA密钥的指定子集)以外的所有参数。 然后，我们将它们按字母顺序排列，最后得到以下内容：

{
 “e”: “AQAB”, 
 “kty”: “RSA”,
 “n”: “10iGQ5l5IdqBP1l5wb5BDBZpSyLs4y_Um-kGv_se0BkRkwMZavGD_Nqjq8x3-fKNI45nU7E7COAh8gjn6LCXfug57EQfi0gOgKhOhVcLmKqIEXPmqeagvMndsXWIy6k8WPPwBzSkN5PDLKBXKG_X1BwVvOE9276nrx6lJq3CgNbmiEihovNt_6g5pCxiSarIk2uaG3T3Ve6hUJrM0W35QmqrNM9rL3laPgXtCuz4sJJN3rGnQq_25YbUawW9L1MTVbqKxWiyN5WbXoWUg8to1DhoQnXzDymIMhFa45NTLhxtdH9CDprXWXWBaWzo8mIFes5yI4AJW4ZSg1PPO2UJSQ”
}

We then remove all whitespace:

然后，我们删除所有空格：

{“e”:“AQAB”,“kty”:“RSA”,“n”:“10iGQ5l5IdqBP1l5wb5BDBZpSyLs4y_Um-kGv_se0BkRkwMZavGD_Nqjq8x3-fKNI45nU7E7COAh8gjn6LCXfug57EQfi0gOgKhOhVcLmKqIEXPmqeagvMndsXWIy6k8WPPwBzSkN5PDLKBXKG_X1BwVvOE9276nrx6lJq3CgNbmiEihovNt_6g5pCxiSarIk2uaG3T3Ve6hUJrM0W35QmqrNM9rL3laPgXtCuz4sJJN3rGnQq_25YbUawW9L1MTVbqKxWiyN5WbXoWUg8to1DhoQnXzDymIMhFa45NTLhxtdH9CDprXWXWBaWzo8mIFes5yI4AJW4ZSg1PPO2UJSQ”}

Finally, we create a hash of the resulting JSON, and base64url encode the hash to get the thumbprint. RFC 7638 does not mandate a specific hashing algorithm, but leaves it up to participants to agree the algorithm among themselves if necessary.

最后，我们创建所得JSON的哈希，然后base64url对哈希进行编码以获取指纹。 RFC 7638并没有强制使用特定的哈希算法，但如果有必要，则让参与者自己同意该算法。

In the case of the Open Banking ecosystem, the hashing algorithm used is SHA1. For our sample JWK, we can compute the hash using openssl as follows (as before, we use sed to manually transform the base64 encoding to base64url).

在开放银行生态系统的情况下，使用的哈希算法为SHA1 。 对于我们的示例JWK，我们可以使用openssl如下计算哈希值(像以前一样，我们使用sed手动将base64编码转换为base64url)。

echo -n '{"e":"AQAB","kty":"RSA","n":"10iGQ5l5IdqBP1l5wb5BDBZpSyLs4y_Um-kGv_se0BkRkwMZavGD_Nqjq8x3-fKNI45nU7E7COAh8gjn6LCXfug57EQfi0gOgKhOhVcLmKqIEXPmqeagvMndsXWIy6k8WPPwBzSkN5PDLKBXKG_X1BwVvOE9276nrx6lJq3CgNbmiEihovNt_6g5pCxiSarIk2uaG3T3Ve6hUJrM0W35QmqrNM9rL3laPgXtCuz4sJJN3rGnQq_25YbUawW9L1MTVbqKxWiyN5WbXoWUg8to1DhoQnXzDymIMhFa45NTLhxtdH9CDprXWXWBaWzo8mIFes5yI4AJW4ZSg1PPO2UJSQ"}' | openssl sha1 -binary | openssl base64 | sed 's/+/-/g; s/\//_/g; s/=//g'

This gives us the following thumbprint:

这为我们提供了以下指纹：

EF71iSaosbC5C4tC6Syq1Gm647M

By using this value in the "kid" field of our token header, we can be sure that relying parties can find the corresponding public key in the JWK published by the Open Banking Directory.

通过在令牌标题的"kid"字段中使用此值，我们可以确保依赖方可以在Open Banking Directory发布的JWK中找到相应的公钥。

结论 (Conclusion)

Key identifiers are a critical part of the token validation process for OpenID Connect and any other JWS based trust model. They provide the means for correlating JOSE signatures with their corresponding keys, and deserve careful consideration when building an authentication and authorisation ecosystem. Using a standard such as RFC 7638 ensures robust and unique key identifiers in large scale environments, with consistency of KIDs between all participants.

密钥标识符是OpenID Connect和任何其他基于JWS的信任模型的令牌验证过程的关键部分。 它们提供了将JOSE签名与其对应的密钥相关联的方法，并且在构建身份验证和授权生态系统时应仔细考虑。 使用诸如RFC 7638之类的标准可确保在大型环境中使用健壮且唯一的密钥标识符，并使所有参与者之间的KID保持一致。

In the next article, we’ll look at how to implement standards based key identifiers in real life, using the ForgeRock Identity Platform.

在下一篇文章中 ，我们将研究如何使用ForgeRock Identity Platform在现实生活中实现基于标准的密钥标识符。

翻译自: https://medium.com/@christian.brindley/json-web-signatures-kids-and-thumbprints-sticking-to-standards-cadec192add1

json怎么表述指纹