Hi @greggoryaddison ,
Good question - and it points out some differences (and similarities) with PlayFab.
Playfab rationalized that they didn't need a client secret because:
- it wouldn't be secure anyway
- and they had separate CLIENT vs. SERVER APIs.
Well - brainCloud actually has the same API separation - in our CLIENT vs. S2S APIs -- but we figure security is all about layering - and so we still require the app secret in the client.
But note that this app secret is SEPARATE from the secrets that get use for privileged SERVER/S2S API calls. When you declare an external server interface a separate secret is generated just for that interface. And that secret you'd normally keep in a .env file on server... Our Builder API uses a similar concept (also with separate API keys).
The brainCloud CLIENT APIs are very sandboxed. You can only access info about your player -- you explicitely can't access information about other players. You can also use API Blocking to prevent even those sandboxed calls from being done from the client. And implement sensitive calculations and operations in cloud code scripts that run on the server.
So - the app secret isn't as sensitive as you'd think.
That said - there are some best practices to improve things:
- Store it in a configuration file (not the source itself). That makes it easier to swap builds across dev/staging/prod versions of your app. Add it to .gitignore to ensure it isn't store in your source repo directly.
- Ideally obfuscate the string in storage - so it's harder [though not impossible] for attackers to read
So - in summary - the app secret that our client uses is an additional layer of security that Playfab doesn't have. It is still separate from the secrets that the privileged S2S and Builder APIs use - so there's no compromise there.
I hope that helps to clarify things!
More info here - https://help.getbraincloud.com/en/articles/14855017-storing-your-app-secret-safely
Paul.
