The Duo OIDC client secret key is a 40 character alphanumeric (^[a-zA-z0-9]*$) string. The key is used as a pre-shared secret between the client and Duo. Duo use, and only use, the HS512 algorithm to compute a hashed message authentication code (HMAC) in order to preserve JWT integrity and prove authenticity.
The 40 character secret key is stored internally as a 16 bit (UTF-16) Java String but converted by the Auth0 libraries to a byte array (to get the key in bits) assuming a UTF-8 encoding. As the characters pool is limited to a subset of ASCII, the 40 character secret is represented by 40 bytes. It is this array of 40 bytes (320 bits) that is used as the secret key to generate the JWS authentication code.
According to the JSON Web Algorithms (JWA) Specification (RFC7518), the secret key length must be the same size as the size of the hash output or larger - this can also be observed as a recommendation in the HMAC RFC (RFC2014 section 2). For HS512 for example, as the output size is 512bits, according to both ‘best practice’ and the JWA specification the key length must be at least 512bits. That means the Duo Secret key should be at least 64 characters assuming a UTF-8 encoding of the restricted character set, or better, as a more complex (higher entropy) 512bit string base64 encoded.
Primarily there are security implications from using ‘weaker’ keys and hence 'weaker' HMACs. In addition, for our implementation going forward, Duo’s OIDC authorization endpoint requires a signed Request JWT, and the token endpoint requires a signed client_assertion JWT. The Java Nimbus OIDC-JWT library follows the JWA specification closely in terms of generating a JWS and is unable to generate a HS512 signature using the existing 40 character string key (UTF-8 encoded). Because of this, we can not directly use Nimbus to either; create the authorization request JWT parameter, or create the JWT used for exchanging the auth_code for the id_token .
This also implies the Duo authorization service is generating a JWS using the same (not recommended) private key length and algorithm.
This requirement is echoed in other specifications e.g. IPSec also fixes the key length to the output length of the algorithm used for authentication/integrity cases (RFC4868), and TLS uses the same key length as the hash function output.