Hacker News Reader

Comment by ncann | Hacker News Reader

Isn't API key pretty much can always be recovered client side? If API key is hardcoded in the app it's trivial to get. If it's dynamically fetched it's also trivial to intercept the network call. I don't think there's anything you can do to prevent that.

View on HN

Well, the safe approach is to either have the user provide their own API key, or to perform requests on the backend (after verifying the user has an account, correctly authenticated, has paid and deducting from their quota).

Or you could generate a per-user subkey with a quota if the upstream service supports that.

OpenAI API has a larger surface area than just completions. You can retrieve files uploaded through it, you can generate images, you can use the embedding API, you can use a different, more expensive model (GPT4) - and make as many calls as you wish. With a backend, you can restrict what is allowed, add your own rate limiting, you can rotate keys etc.

The replies suggest storing the API key on a backend which you control.

Yeah you can try obfuscating it, but in general you need to assume plain text access to anything you send the client.

The only exceptions are basically some really hardcore DRM like denuvo and hardware certificated drm. Even those aren't safe from deteremined people.

You can have a server side proxy for authenticated and authorised users, with a rate limit.

From comments here, I suppose you could make your app cloud-based so your client app is just a UI and only your trusted backend has full access to the external API, and that sounds dystopian.

Why is that dystopian? Sounds like the standard, good-idea architecture for an application that communicates with a paid 3rd party API.

It's... pretty normal practice.

That's what these applications are already doing. The only difference is their cloud back-end is openai's API instead of something they control themselves.

Reply on news.ycombinator.com