0

I am working on a three-layer application with the server, client, and database. The client is a java fat client. I need to generate tokens(= API keys) for access to the rest API. The hash value of these tokens will be saved to the database.

Now I am struggling a bit if I should generate the token on the server or on the client-side.

Server:

  • token generation is centralized

Client:

  • token will not be sent across the web, only the hash

Can you give me any advice, what is the "state-of-the-art" to do this?

Philemon Hilscher
  • 131
  • 4
  • 1
    If the client only sends the hash then there basically is no hashing, the hash becomes the password: https://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-client-side - so now your options are for the client or the server to *generate* the token, the server is always the one who hashes. And then the question is: why would a client need to set his token, you only risk a client reusing api keys between different apps. And the API key should be unique which a client cannot guarantee, only the server can randomly choose a new one. – luk2302 Feb 17 '21 at 16:37
  • I'd say state of the art would be to use a proper auth mechanism such as OAuth 2 or OpenID connect which is based on OAuth 2. – Thomas Feb 17 '21 at 16:42
  • Okay, i forgot to mention that the token generation and the access to the api are two seperate applications which are connected to the same database. So if the token is generated on the client, saved as a hash by the server it can be used by the second "rest-server" to authenticate any incoming request. – Philemon Hilscher Feb 17 '21 at 16:50

0 Answers0