I have a Desktop API written in C++. Within this API I call a REST API to register with my service (using typical email user validation). The REST API is protected with a ID and SECRET; the requests, including the ID, are HMAC'ed with the secret, in a typical manner.

Storing an ID and SECRET in a desktop app is obviously a vulnerability waiting to be exploited. what are other options or best practices in this scenario?

1 Answer 1


If access to your REST API needs to be restricted, you should treat it like any web application. Using a fixed secret token is a security through obscurity technique, which runs counter to accepted security principles such as Kerckhoffs's principle and Shannon's maxim.

The standard mechanism for authentication in REST APIs is an API key, which is a long random token given to users. The API key acts as both a username and password, in that it is unique and secret.

There are two ways to provide this kind of authentication:

  • Send the API key with every request, and validate it each time. This requires less code, but means you have to send your secret in every request, which creates more risk.
  • Send the API key as part of a "login" request, then return a session ID. That session ID becomes the security mechanism for the rest of the session, so you don't have the problem of sending the API key every time. After the session times out, the API key must me sent again. Unfortunately this results in more code and more potential for errors.

Since you should be using HTTPS for both methods anyway, I'd go with the first option. Transport security allows you to prevent modification of payloads, and keeps your API key secret.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.