I have a C# app that is sending post requests to and from a php script. I have token based authentication setup on the php, and I have my C# app sending the tokens, however, even with obfuscation, if someone gets my token string, having it there in the first place is useless. Is there a better way to do this kind of security? Is it impossible considering someone can just deobfuscate my source?

  • Not sure I understand. Do you have the secret token in the C# source code? And you want to remove it from there?
    – Anders
    Sep 24, 2018 at 8:13

1 Answer 1


It sounds like you, as many before you have done, are trying to make it so only an "authorized" client can access your online API (presumably a web service). This, as you suspected, is impossible. You can take many steps to make it harder for somebody to write a functional unauthorized client (obfuscation, encrypting the tokens locally, blocking the use of an intercepting proxy by employing certificate pinning, various other DRM schemes, etc.) but at the end of the day, if you give users a working client, they can (and, if they have any reason to bother, will) duplicate everything that client does so that your server thinks it's legit.

The bigger question is, why do you care? There are generally only a few reasons people try to prevent unauthorized clients:

  1. They are putting too much trust in the client. An example might be an online game where the client tells the server whether or not the user won, instead of the client telling the server what the user did and the server deciding who won. Never trust the client.
  2. The service is expensive to use in some way (monetarily, computationally, storage-wise, whatever) and they want to limit how frequently requests can be made to it. The correct approach here is to require authentication of the user, rather than the client, and either charge the user or limit the number of requests they can make.
  3. They don't want people automating interaction with the service, for example because it's a game with a lot of repetitive behavior and they don't want people writing bots for it. In that case, tough. There's only so much that can be done against this, and it usually comes down to some kind of human review of replays or something like that to detect cheaters.
  4. They want to only support specific users (for example, they don't want to bother with a Linux app) and are worried that if somebody ports their app then they'll get bombarded with support requests for code they didn't write. Honestly, there's no good way around this one (aside from trademarking your service name and using legal threats against anybody who tries to publish something as you, but that doesn't stop them from publishing something that is "an unofficial YourService(TM) client").

If it's something else, please add the relevant info to your question and I'll address that. Overall, though, it cannot truly be done. You cannot give somebody the key to a door but prevent them from copying it or sharing it.

You must log in to answer this question.