Why does Spring's default OAuth JWT implementation make the JWT verifier public?

Question

Spring's default OAuth JWT flow (using client_credentials grant) is as follows:

1. Launch the Auth Server (AS)
2. Launch the Resource Server (RS)
   • At startup the RS requests the tokenKey by calling GET /oauth/token_key using Basic Auth
3. The AS returns a PUBLIC KEY using RS256 (SHA256withRSA)
4. Some time later, the Client requests an accessToken by calling GET /oauth/token using the client_credentials grant
5. The AS returns a JWT accessToken containing a JWS signature
6. The Client sends the JWT as a Bearer token to the RS
7. The RS uses the tokenKey that it received from the AS at startup to verify that the JWT accessToken came from the AS. This is where I get confused...

Is this secure? Why would a public cert be used rather than a shared secret key? Couldn't a hacker easily obtain the public key and sign their own valid JWT accessToken? How does the usage of the public key cert and the JWT signature work together to verify that the sender was actually the Auth Server and not an attacker?

Any insight would help.

Answer 1

Some research into the nature of public key cryptography and digital signatures gleans this:

Digital signatures implement asymmetric cryptography. A digital signature gives the receiver reason to believe the message was sent by the claimed sender. Similar to a handwritten signature they are difficult to forge. The signer, in this case, the AS, uses a secret PrivateKey to create the signature. Some non-repudiation schemes offer a time stamp for the digital signature, so that even when the PrivateKey is exposed, the signature is valid.

A digital signature scheme typically consists of 3 algorithms

1) A key generation algorithm that selects a PrivateKey uniformly at random from a set of possible private keys. The algorithm outputs the private key and a corresponding public key.

2) A signing algorithm that creates a signature using the message and the private key

3) A signature verifying algorithm that, given the message, PublicKey and signature, either accepts or rejects the message's claim to authenticity.

In this case (RS256), the signature was created using SHA256withRSA which is not used as an encryption algorithm, rather it is used to verify the origin or the authenticity of the data. The signature was generated using a private key. The public key is passed to the Resource server to be used to verify the signature. In this scenario, even if an attacker has the PublicKey, they cannot create a spoof message with the signature or alter the contents.