ruby-jwt | ruby implementation of the RFC 7519 OAuth JSON Web Token | Authentication library

The reason is the base64url encoding. The three parts of a JWT are all base64url encoded. Base64 encoding transforms the input data to a 6-Bit representation, mapped to a set of 64 ASCII characters. If you have 3 bytes source data, the base64 encoded result is 4 characters long, each character representing a 6 bit value, so 4 * 6 bits = 24 bits.

In your case, the encoded signature has 43 characters, which means 43 * 6 = 258 bits. So you could theoretically encode 258 bits, but the signature is only 256 bits (32 byte) long, which means there are 2 insignificant bits on the end.

A look on the base64 encoding table shows that 'A' to 'D' represent the 6 bit values 0 (000000) to 4 (000011), so the first four bits, which are still significant, are all identical, and only the last two, insignificant bits are changing. But the character 'E' stands for 5 (000100) and would change the last bit of the 256 bit value.

Conclusion: it's all fine, nothing wrong here, it works as expected.

1. Try to use the token generator (https://developers.docusign.com/oauth-token-generator) and see if that token works for you. That would isolate the issue to obtaining the token.
2. Make sure in the sandbox admin, you configured your IK correctly, and that you use the exact same one.
3. You need an RSA key generated and make sure to use it for JWT.
4. Make sure you point to account-d.docusign.com and not account.docusign.com (so you use our developer sandbox and not production)

For Ruby 2.4+ you should use :

JWT is not for encryption, but for identification.

The JWT generator signed the payload with a private key, you can verify if it is generated by the specific generator or not, using a public key. But the payload is not encrypted, anyone can read it.

For example. John sends you a message that "he is at home.", and signed it by his private key. Everyone can read this message but you can verify it is really sent by John, not someone else like Alice.

RSA keys, and "the RSA algorithm" don't have any notion of a hash algorithm.

An RSA key is just two prime numbers and one other number (from the (p, q, e) triplet all the other values can be derived). e is usually chosen as 0x010001 (though other reasonable values exist) and p and q are generated randomly (while almost any CSPRNG is going to have a backing hash algorithm the CSPRNG itself is usually considered a black box that just emits randomness).

Where a hash algorithm comes into play is in RSA Signatures.

For an RSA Signature the original data is hashed under an algorithm and then the hash value, algorithm identifier, and private key are used to produce a signature (for PKCS v1.5 signatures... for PSS there's also a second (effectively fixed) identifier and some more random bytes).

RS256 is the JWA (JSON Web Algorithms) identifier for "RSASSA-PKCS1-v1_5 using SHA(-2)-256".

JWA section 3.3 says

This section defines the use of the RSASSA-PKCS1-v1_5 digital signature algorithm as defined in Section 8.2 of RFC 3447 [RFC3447] (commonly known as PKCS #1), using SHA-2 [SHS] hash functions.

A key of size 2048 bits or larger MUST be used with these algorithms.

The RSASSA-PKCS1-v1_5 SHA-256 digital signature is generated as follows: generate a digital signature of the JWS Signing Input using RSASSA-PKCS1-v1_5-SIGN and the SHA-256 hash function with the desired private key. This is the JWS Signature value.

(emphasis mine)

So no requirement is made on the RSA key, other than that the spec was written in 2015 so they mandated a 2015-compatible minimum keysize.