I'm setting up an API which will be used primarily over HTTPS (only calls not needing any security what so ever is available over HTTP). Some aspects of it need to be accessed only by authenticated users. To allow this without using passwords each user possesses one or more RSA keypairs. The public key is kept on the API server.
When the user want to be authenticated they sign the current timestamp with their private key and send it, the timestamp and an ID to what keypair was used over to the server.
The server verifies that the message (the timestamp) was signed by a user with the corresponding key.
The server verifies that the timestamp has not surpassed a certain amount of time and returns a JWT token signed with the server's private key which will be used later to authenticate the user.
The timestamp (which acts as a nounce(?) and a way to restrict access according to time) should not be sent along with the authentication request to the server, since knowing what message was signed the key could be reverse engineered.
An uncautious user could misplace a signed key which would practically be just as bad as losing a password if not worse.
Is it wrong supplying what "nonce" that was signed along with the request or should the server already "know" (via some previous exchange)?
Does using the timestamp as a message when creating the signature defeat rogue digests? I.e. is it enough to make the digest unusable after the expired time - since the message can't be altered without not passing a verification?