Concealing API key for offline apps?

Hey! I’m Sam, I make projects like the Desktop Goose.
I’d love to integrate patreon into my projects by allowing users to connect their accounts using the OAuth API and providing specific features/experiences conditional on their support.
Seems like a pretty awful idea to just plop the secret key and do the authentication client-side, given how easy it is to decompile.
I also have zilch web experience. So total newbie question: Is there a good possible way to securely make a microservice to authenticate Patreon users, while concealing the API tokens/keys from the client? Is there an existing service I can use that already does something similar?

Thanks a ton,
Sam

You would need some way to authenticate/idenfity the offline app in some way. So either you have the token saved in the offline map, or the app itself has its own key which authenticates it to an authentication service, which then allows access to the api token to contact Patreon.

Another alternative is to regularly have the user go through a smooth login via Patreon process (like how WP plugin implements) and then copy in the patronage info of the user to use it locally.

But in any case, you will eventually have to authenticate the local desktop app to Patreon in order to allow user access to patron only content. Otherwise the local copies of the patronage info could allow user infinite access to online or local content.

Thanks so much for your response!
Would it make sense to have the offline app open a ‘login with patreon’ web interface, which after a successful login, sends the user’s oauth token back to the app to be cached on their local machine?

Then use that for API calls, without exposing my secret keys.
Edit: No, I’d need to expose the refresh token which is also supposed to be secret. Hm. Alright, no easy way out of this one.

That could be a solution indeed i think. You could put online an api of your own to keep your own secret keys, somehow have users login through Patreon via your app every now often (via web), and redirect the user to the local app via your login api with the tokens without user even seeing anything on the web. Or something similar.

An in-app mini browser inside the local desktop apps may also be an option.Then the process will be seamless.

Hi all, :slight_smile:

I have a web browser extension called Sprucemarks which even though it lives in a web browser, has many of the same concerns as an offline app. Concerns like…

  • Users must be online at least once to login to Patreon.
  • Once logged in, how long do you let the software stay unlocked before checking in again?
  • Including anything secret in the distributable is NOT an option since web browser extensions are basically unprotected.

Distributing sensitive keys is obviously not an option so I ended up making a web service to handle OAuth keys, refresh tokens, and anything else that could be kept away from the client. Launched earlier this year, here is how things currently flow.

  • Users install and run the software.
  • Users are prompted to login via Patreon.
  • Users are redirected to Patreon where they login if needed.
  • Logged in users are given a choice to “Allow” or “Deny” sharing their account information.
  • Users that “Allow” sharing are redirected to my web service which now has a one-time use token to setup a relationship.
  • The web service connects to Patreon and gets all the Patreon info it needs, including access and refresh tokens.
  • Users are redirected back to the software which in my case, checks if they are an active Patreon or if they donated $7 over the life of their account. If yes to either, the software unlocks.

Phew, that was a lot of steps but that only covers the initial login. Because Patreons can change their donation amounts, deactivate, reactivate, receive refunds, or even change their names, the client software needs to check in with the web service every once in awhile. As long as a check-in happens once every 30 days, the web service gets fresh info, uses a refresh token if needed, and keeps that connection with Patreon going. If a user shuts off their computer for 6 months well then… they are going to need to login via Patreon again.

The check-in process above is what my web service is currently setup to do but you could make yours fancier and have it automatically use refresh tokens, even when users do not check-in. Then your server would always be at maximum readiness for users. Just probably want to add some logic so a user who has not been seen for X days or X months triggers the server to stop checking on their account. No use doing extra work if a user seems unlikely to return anytime soon.

While there are some things that can not be avoided, like having a Patreon login or having some kind of check-in on a schedule, there really are a lot of ways you could set things up. It certainly does require a bit of work but there is also a lot of room for creativity, depending on how you want to handle different scenarios.

1 Like