We have a website using PWA Client calls / Mobile APP, all using the same APIs. We have APIs Exposed to Public. Currently, our APIs are not secure meaning that anyone can check APIs signature via developer tools/proxy tools and hit the API.

We want our APIs to be hit by verified clients. Verified clients do not mean logged in clients. Our website can be used by non-logged in users as well. Clients here mean users accessing the website via browsers/app.

So for that, we are planning that we will allow those APIs only which have the registered/enabled token and that will be sent via header.

Now to generate the token:

  1. Device ---- sends Token(B) Request----> Server
  2. Server generates Token(B) and returns it and stores it in Redis
  3. Device ---- sends Token(B) to enable request-----> Server
  4. The server enables it
  5. The device sends Token(B) in all subsequent requests
  6. The server checks whether the token exists in Redis in the enabled state or not

Since these register/enable token APIs are also exposed publicly, to ensure no one is able to hack this process:

  • While enabling the token, we also send the Encrypted token(A) alone with the actual token(B).
  • At the server, we decrypt the token(A) and matches it with the normal Token(B).

Encryption is done using the private key known to client/Server only.

Is this the right approach and this is vulnerable? The only issue is seen is that register/enable token APIs are exposed publically. But we have also added the security to that, is that good enough?

  • It is not possible to verify clients. HTTP simply was not designed for it. Although to be fair, it's not just HTTP where the problem lies. In essence you are trying to implement DRM, and while it is possible to make it harder for an "unauthenticated" client to use your API, it is quite literally impossible to prevent it. The better approach, unless you have a compelling reason otherwise, is to simply not bother trying. Just make sure and require a login for any data that isn't supposed to be public. Jul 9, 2020 at 8:46
  • In this case, from what I gather, a user could easily grab Token(B), copy it to a new device/client, and make calls to your API without issue. Also, any attempt to embed a private key in a client and keep it private is futile. It can be pulled out of an app with reverse engineering tools and it would be especially easy to pull out of a web app. Jul 9, 2020 at 8:49


You must log in to answer this question.

Browse other questions tagged .