In JWT both Header and Payload is encoded to make it URL Safe but not encrypted. So any one can see the content after decoding the Header and Payload. We cannot send any sensitive data using JWT.The signature is created using the header, the payload, and the secret that is saved on the server.

   Signature = Header + Payload + Secret

The above process is Signing the JSON Web Token. The signing algorithm takes the header, the payload, and the secret to creating a unique signature. So only this data plus the secret can create this signature. Together with the header and the payload, these signature forms the JWT, which then gets sent to the client.

Once the server receives a JWT to grant access to a protected route, it needs to verify it in order to determine if the user really is who he claims to be. In other words, it will verify if no one changed the header and the payload data of the token. So again, this verification step will check if no third party actually altered either the header or the payload of the JSON Web Token.

The signature is an HMAC, which uses a particular type of cryptographic function. Such an HMAC algorithm is indicated with the “HS” prefix, as shown in the sample token above. The HMAC takes the header, the payload, and a secret key as input, and returns a unique signature over all three inputs. Service uses the same secret key to calculate the HMAC of the JWT. If the resulting HMAC is the same as the signature in the token, the service knows that all three inputs to the HMAC function were the same as before.

{
   "typ":"JWT",
   "alg":"HS256"
}

How Verification is Carried to check whether payload has been changed?

Once the JWT is received, the verification will take its header and payload, and together with the secret that is still saved on the server, basically create a test signature.

The original signature that was generated when the JWT was first created is still in the token which is the key to this verification. We have to compare the test signature with the original signature. And if the test signature is the same as the original signature, then it means that the payload and the header have not been modified. If they had been modified, then the test signature would have to be different. Therefore in this case where there has been no alteration of the data, we can then authenticate the user. And of course, if the two signatures are actually different, well, then it means that someone tampered with the data. Usually by trying to change the payload. Third party manipulating the payload does not have access to the secret(Private key used to sign), so they cannot sign the JWT. So the original signature will never correspond to the manipulated data. And therefore, the verification will always fail in this case.

Limitations of Symmetric Signatures
This signature scheme is straightforward. It is also the typical scheme used to explain JWTs to developers. Unfortunately, symmetric signatures prevent the sharing of the JWT with another service. To verify the JWT’s integrity, all services would need to have access to the same secret key. However, possession of the secret key is enough to generate arbitrary JWTs with a valid signature.

Sharing the HMAC secret with a third-party service creates a significant vulnerability. Even sharing the secret between different services within a single architecture is not recommended. If all services share the same key, the compromise of a single service immediately becomes an architecture-wide problem.

Instead of sharing the secret HMAC key, you can opt for using asymmetric signatures

Note: The above could be helpful of the Authorization Server and Resource Server is same.

Link to Repo