問題描述

我已經(jīng)開始使用 JJWT 來處理我的服務(wù)器應(yīng)用程序上的 JWT.

I have started to work with JJWT to handle JWT on my server application.

我的 JWT 機(jī)密將存儲在 resources 文件夾中，我將使用 Properties 類加載該機(jī)密.

My JWT secret will be stored at resources folder and I will load the secret with Properties class.

JJWT 提供了三種對 JWT 進(jìn)行簽名的方法，一種使用 byte[]，其他使用String，其他使用Key:

The JJWT provides three methods to sign the JWT, one uses byte[], other uses String and the other uses Key:

JwtBuilder signWith(SignatureAlgorithm var1, byte[] var2);

JwtBuilder signWith(SignatureAlgorithm var1, String var2);

JwtBuilder signWith(SignatureAlgorithm var1, Key var2);

問題:關(guān)于安全、字符集和其他方面，我應(yīng)該使用哪一個(gè)有什么建議?

The question: Regarding security, charset and other things, there are any recommendations of which one I should use?

暫時(shí)，我支持 String，因?yàn)?Properties 返回一個(gè) String.

For while, I stand with String, since Properties return a String.

推薦答案

在 JJWT >= 0.10.0 的情況下，signWith(SignatureAlgorithm var1, String var2) 已被棄用，因?yàn)樗鼈冎g存在混淆字符串和 Base64 編碼的字符串:

With JJWT >= 0.10.0, signWith(SignatureAlgorithm var1, String var2) has been deprecated because of the confusion between raw strings and Base64-encoded strings:

/**
 * Signs the constructed JWT using the specified algorithm with the specified key, producing a JWS.
 *
 * <p>This is a convenience method: the string argument is first BASE64-decoded to a byte array and this resulting
 * byte array is used to invoke {@link #signWith(SignatureAlgorithm, byte[])}.</p>
 *
 * <h4>Deprecation Notice: Deprecated as of 0.10.0, will be removed in the 1.0 release.</h4>
 *
 * <p>This method has been deprecated because the {@code key} argument for this method can be confusing: keys for
 * cryptographic operations are always binary (byte arrays), and many people were confused as to how bytes were
 * obtained from the String argument.</p>
 *
 * <p>This method always expected a String argument that was effectively the same as the result of the following
 * (pseudocode):</p>
 *
 * <p>{@code String base64EncodedSecretKey = base64Encode(secretKeyBytes);}</p>
 *
 * <p>However, a non-trivial number of JJWT users were confused by the method signature and attempted to
 * use raw password strings as the key argument - for example {@code signWith(HS256, myPassword)} - which is
 * almost always incorrect for cryptographic hashes and can produce erroneous or insecure results.</p>
 *
 * <p>See this
 * <a href="https://stackoverflow.com/questions/40252903/static-secret-as-byte-key-or-string/40274325#40274325">
 * StackOverflow answer</a> explaining why raw (non-base64-encoded) strings are almost always incorrect for
 * signature operations.</p>
 *
 * <p>To perform the correct logic with base64EncodedSecretKey strings with JJWT >= 0.10.0, you may do this:
 * <pre><code>
 * byte[] keyBytes = {@link Decoders Decoders}.{@link Decoders#BASE64 BASE64}.{@link Decoder#decode(Object) decode(base64EncodedSecretKey)};
 * Key key = {@link Keys Keys}.{@link Keys#hmacShaKeyFor(byte[]) hmacShaKeyFor(keyBytes)};
 * jwtBuilder.signWith(key); //or {@link #signWith(Key, SignatureAlgorithm)}
 * </code></pre>
 * </p>
 *
 * <p>This method will be removed in the 1.0 release.</p>
 *
 * @param alg                    the JWS algorithm to use to digitally sign the JWT, thereby producing a JWS.
 * @param base64EncodedSecretKey the BASE64-encoded algorithm-specific signing key to use to digitally sign the
 *                               JWT.
 * @return the builder for method chaining.
 * @throws InvalidKeyException if the Key is insufficient or explicitly disallowed by the JWT specification as
 *                             described by {@link SignatureAlgorithm#forSigningKey(Key)}.
 * @deprecated as of 0.10.0: use {@link #signWith(Key)} or {@link #signWith(Key, SignatureAlgorithm)} instead.  This
 * method will be removed in the 1.0 release.
 */
JwtBuilder signWith(SignatureAlgorithm alg, String base64EncodedSecretKey);

此方法要求字符串參數(shù)是 Base64 編碼的密鑰字節(jié)數(shù)組.它不假設(shè)一個(gè)通用字符串，例如用戶密碼，作為簽名密鑰.JJWT 采用 Base64 編碼，因?yàn)槿绻付ǖ淖址艽a不是 Base64 編碼的，那么您可能使用了格式不正確或弱的密鑰.

This method expects the string argument to be a Base64-encoded secret key byte array. It does not assume a general string, like a user password for example, as the signing key. JJWT assumes Base64 encoding because if you're specifying a string password that is not Base64-encoded, you're probably using a poorly formed or weak key.

JWT JWA 規(guī)范要求 HMAC 簽名密鑰的長度等于或大于簽名字節(jié)數(shù)組長度.

The JWT JWA specification REQUIRES that HMAC signing keys have lengths equal to or greater than the signature byte array length.

這意味著:

| If you're signing with: | your key (byte array) length MUST be: |
| ----------------------- | ------------------------------------- |
| HMAC SHA 256            | >= 256 bits (32 bytes)                |
| HMAC SHA 384            | >= 384 bits (48 bytes)                |
| HMAC SHA 512            | >= 512 bits (64 bytes)                |

許多在線 JWT 網(wǎng)站和工具只是犯了這個(gè)明顯的錯(cuò)誤——它們讓您認(rèn)為您可以輸入或使用任何舊字符串并且您很好.有些人甚至使用 secret 這個(gè)詞預(yù)先填充密鑰(顯然是個(gè)壞主意，甚至不符合規(guī)范，因?yàn)樗塘耍?.

Many online JWT sites and tools just just get this plain wrong - they allow you to think that you could type in or use any old string and you're good. Some go as far as even pre-populating the key with the word secret (clearly a bad idea and not even spec-compliant because it's too short!).

為了幫助您簡化事情，JJWT 提供了一個(gè)實(shí)用程序來幫助您生成足夠的安全隨機(jī)密鑰，以通過 io.jsonwebtoken.security.Keys 類的 secretKeyFor 進(jìn)行符合規(guī)范的簽名 方法.例如:

To help simplify things for you, JJWT provides a utility to help you generate sufficient secure-random keys suitable for spec-compliant signing via the io.jsonwebtoken.security.Keys class's secretKeyFor method. For example:

//creates a spec-compliant secure-random key:
SecretKey key = Keys.secretKeyFor(SignatureAlgorithm.HS256); //or HS384 or HS512

如果你想將生成的密鑰存儲為字符串，你可以推測它是 Base64 編碼:

If you wanted to store the generated key as a String, you could presumably Base64 encode it:

String base64Key = Encoders.BASE64.encode(key.getEncoded());

但請注意:生成的 base64Key 字符串不被認(rèn)為可以安全地顯示給任何人.Base64 編碼不是加密 - 該值仍然需要保密.如何執(zhí)行此操作取決于您(加密等).

But note: the resulting base64Key string is not considered safe to show to anyone. Base64 encoding is not encryption - the value still needs to be kept secret. How you do this is up to you (encrypt it, etc).

現(xiàn)在，當(dāng)需要?jiǎng)?chuàng)建 JWS 時(shí)，您可以傳入該 base64Key 值，JJWT 知道首先對其進(jìn)行 base64 解碼以獲取實(shí)際字節(jié)，然后用于計(jì)算簽名:

Now, when it is time to create a JWS, you could pass in that base64Key value, and JJWT knows to base64 decode it first to get the real bytes, which are then used to compute the signature:

Jwts.builder()
    //...
    .signWith(SignatureAlgorithm.HS512, base64Key)
    .compact();

雖然您可以這樣做，但由于原始字符串和 base64 編碼字符串之間的歧義，不建議按照 JavaDoc 中的上述棄用通知.

And while you could do this, it is not recommended per the above deprecation notice in the JavaDoc due to the ambiguity between raw strings and base64-encoded strings.

因此，建議使用 JWT 構(gòu)建器的 signWith(Key) 或 signWith(Key, SignatureAlgorithm) 方法來保證類型安全 鍵參數(shù).例如:

As a result, it is recommended to use either the JWT builder's signWith(Key) or signWith(Key, SignatureAlgorithm) methods which guarantee a type-safe Key argument. For example:

  Jwts.builder()
    //...
    .signWith(key) // or signWith(key, preferredSignatureAlgorithm)
    .compact();

signWith(Key) 建議讓 JJWT 根據(jù)您提供的密鑰的強(qiáng)度找出可能的最強(qiáng)算法.signWith(Key,SignatureAlgorithm) 允許您指定所需的算法，如果您不想要最強(qiáng)的算法.

signWith(Key) is recommended to let JJWT figure out the strongest algorithm possible based on the strength of your supplied key. signWith(Key,SignatureAlgorithm) allows you to specify a desired algorithm if you don't want the strongest possible one.

這兩種方法都會拒絕任何不符合最低 RFC 要求的 Key.

Both methods will reject any Key that doesn't meet the minimum RFC requirements.

這篇關(guān)于靜態(tài)機(jī)密作為字節(jié) []、密鑰還是字符串?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網(wǎng)！