1. Does this Secret has to be unique?

It should be unique to your application — it needs to be a secret, after all — but it won't be unique for each token. Rather, you should have a relatively small number of secret keys at any given time (e.g., usually having just one key, but having brief periods where you have two keys as you rotate from one to the next).

2. Shall I use the hashed version of user's password for secret?

No, for two reasons:

1. Suppose that your user has a relatively insecure password, like GoPackers123. Using the password in your secret then means that someone can easily test a given potential password to see if it results in the right signature; and, more to the point, they can easily test huge numbers of potential passwords to see if any of them gives the right signature. This is an offline attack, so you would never even know it happened.
2. This would require you to distribute all of your users' password hashes to every system that needs to hold the secret. If you have more than a trivial number of users, this can become a pretty serious burden on your secret-distribution mechanism.

JWT and the java-jwt library support both symmetric and asymmetric algorithms for the signature:

• If you go for symmetric algorithms such as HS256, you will have only a single key to be used to sign and verify the signature.

• If you consider asymmetric algorithms such as RS256, you will have a private and a public key. Keep the private key safe on the server and use it to sign the token. Use the public key to verify the signature (it also can be shared with whoever needs to verify the signature).

Never ever share the key used to sign the token!

And nothing stops you from having a set of different keys for signing your tokens. In this situation, the kid header parameter can be used to indicate which key was used to sign the token. This claim is supposed to carry a key identifier and not the key itself.

Refer to this answer for more details on the kid claim.

Use RSA256 i.e. a private/public key-pair (no 'secret' required). That way you can keep the private key secret and safe (it will only be used to sign the token) and you can use the public key to verify that the signature is correct.

You can give the public key to anyone or any service that needs to verify that the token's signature is correct.