2
\$\begingroup\$

I have a tenant ID and client secret that I use to access my server and return an API key for users. I put it in start()

However, hackers can decompile my game and access the server data. Is there any way to secure my tenant ID and client secret in my client code?

\$\endgroup\$
0

1 Answer 1

Reset to default
4
\$\begingroup\$

What is in clients hand is by definition not secret anymore. Regardless what you do, if they are dedicated enough they can get the information that is located inside the client.

Instead why not let the client authenticate itself against the server and let the client just ask for the data? The server would not hand out the api key to the user but the result of the request that the client would make. This has some further benefits:

  • You can cache the results in case multiple clients make often the same requests
  • You know and can control which client is calling how often the endpoint
  • If data manipulation is needed (the return data from the endpoint), you can do this on the backend out of clients sight. In case of huge data this can save the client computation power. It could be a legal requirement. Or you can enrich the data. Or restructure to fit better your client.
  • People just can't take apart your client to recreate your app since the business logic (handling of endpoints, secrets) is not located in the client.
\$\endgroup\$
4
  • 2
    \$\begingroup\$ +1, I've done it this way. It's a big win for rate-limiting, so you can ensure a buggy or hacked client can't degrade server performance for everyone or run up your bills for accessing a third-party service, since you have ultimate control over how often that service actually gets accessed. Your intermediary can also provide graceful fallbacks in the event that the service is unavailable/over-budget, instead of dealing with raw errors in the client. And of course you can monitor this traffic and use it to spot hackers/cheating attempts. \$\endgroup\$
    – DMGregory ♦
    Commented May 26, 2023 at 15:13
  • \$\begingroup\$ I just can't wrap my head around stuff like this. If you (automatically) authenticate with a server to securely ask for data using an API key, the 'hacker' would be able to make this authentication himself and send data requests right? In a rare case, where you would pay per request, this hacker-man could just drain your wallet... Right? \$\endgroup\$
    – M Zeinstra
    Commented Sep 10 at 18:33
  • \$\begingroup\$ @MZeinstra No, the hacker can still do some calls, but your server has the actual control. Lets say you have a 3rd party where you pay per request, depending on the type of service, you might have a cached version of that request on the server already and do not need to pay at all for the request, since you can return it from an earlier call. Or if you find a client that does a higher call rate than expected, you don't call the paid service at all. Yes, the hacker would still get some requests out of you but you keep control and can stop/ block that user from going out of control \$\endgroup\$
    – Zibelas
    Commented Sep 10 at 18:55
  • \$\begingroup\$ @Zibelas Allright, fair enough. I guess requests originating from a client can always be intercepted. But you're right, limiting a 3rd party call rate makes a lot of sense. Thanks! \$\endgroup\$
    – M Zeinstra
    Commented Sep 10 at 19:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .