Client Secrets
When you register an API client you will get a Client ID and Client Secret. These values are used to identify your
application and tell Patreon that the app making the calls to authenticate a user are coming from code you trust.
The Client ID is included in the URL used by your users to sign into Patreon, as such it will always be known to anyone who uses your app and can essentially be considered as public information.
It is impossible to hide your Client ID.
The Client Secret, on the other hand, is not required to be exposed to all your users. It is also used during the authentication process, but it is optional, and if it is used there are
steps you can take to hide it from your users. In general, Client Secrets are meant to be secret, but as long as you can access the same information using only the Client ID it's a bit
of a moot point.
Do I need to use a Client Secret?
The short answer is No. You can leave the Client Secret parameter on PerformAuthentication empty
and everything should work fine, only the Client ID is required.
The long answer is: Patreon's API Documentation always describes the Client Secret as being required for authentication.
While it works fine right now to omit the Client Secret, it might not be something they want to support in the future and this may change. Personally, I'm not worried about this happening any time soon:
Patreon's API is, frankly, poorly supported and seldom updated, so I doubt this will change any time soon (if ever).
If you are building an application which will see ongoing support (like most Patreon-funded games) then the risk of not using the Client Secret is pretty small. In the worst-case
scenario, authentication in older builds breaks and you will have to push an updated build which uses the Client Secret. If you are building an application you no longer intend to support and update, however,
a change to Patreon's authentication could leave your last-published build broken and your users without any way to fix it.
If I want to use a Client Secret, how do I protect it?
The only way to absolutely guarantee no user is able to access your Client Secret is to never allow it to touch their computer in the first place. A typical way to do this would be to create a separate web service which runs on a server
that you control, then when the user signs in to Patreon they are first redirected to that web service (which holds your Client Secret). That service then uses the client secret to complete the user's authentication and cache the user's
tokens, and finally your game client requests the tokens (or information obtained from the Patreon API using those tokens). There are notes on how to work this way using this plugin on the Custom Setup page.
If you don't want to set up an external service, then you will need your game client to have access to the Client Secret. You can take some steps to make it more difficult for a user to extract, but you cannot make it impossible.
- Encrypt the
Client Secretstring, then only decrypt it when you use it and immediately free that string from memory afterwards. - Store the
Client Secret(encrypted) on some external server somewhere where your game client can fetch it, then it will only exist in RAM when your game is running not on disk.
Steps like these can make it more difficult for a user to extract the secret from your game, in the end the secret needs to be sent over the network to Patreon as part of the authentication process. Regardless of how much encryption you apply when the secret is not being used, a user who has the tools to monitor their own network traffic will be able to sniff it out eventually.
The primary risk of having your Client Secret leaked is that someone else could build an application which uses your Client ID and Client Secret to pretend to your game. Users could then be tricked
into signing in to Patreon through this fake app which would now have access to the same information as your game: their names, pledge information related to your campaign, possibly more personal information like their e-mail address, etc.
As long as the Client ID is sufficient to get this information without a Client Secret, though, the Client ID itself can carry this risk.
If you suspect another person has copied your Client ID and/or Client Secret and are trying to trick your users into signing in through some fake game/application, you should immediately
delete your API client and create a new one, then publish an updated build of your application using the new Client ID. This will immediately stop
any bogus app using the old ID from working and will invalidate any access tokens it was able to obtain.
What about access tokens?
When you call PerformAuthentication, a struct containing the user's Access Token is returned.
This Access Token is used to request information on behalf of the user, and as long as the access token is valid (usually for 30 days) using it does not require the user to sign-in again.
The nice thing about this is if you save the token info you can avoid needing to ask the user to sign-in too often. The risk of doing this, however, is that if a user's access token falls into the hands of a hacker, that hacker can also use it to request the same information from Patreon about the user. Because of this, it is recommended to consider whether or not you really need to store the access token, and if so to be careful how you do so.
If you do save the user's access token, it is strongly recommended NOT to save it in plain text. If you encrypt it before writing it to their save file, it will be that much more difficult for an attacker to recognize what it is and figure out how to read it. Rather than just writing a virus which scans everyone's PC for files that look like access tokens, they will have to construct an attack specifically for your game which should greatly reduce the odds that they even bother.
If the in-game rewards you want to unlock for a user are permanently given once unlocked (i.e. you don't want to revoke them if the user unsubscribes from your Patreon campaign), then rather than storing the access token you can just use it once to unlock the content and then only save some information about what content was unlocked. In this case, the access tokens are temporary and don't need to persist on the user's machine.
For any questions, help, suggestions or feature requests, please feel free to contact me at nbpsup@gmail.com