5 ms·

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 tri

by ncann 3y ago

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.

speedgoose 3y ago
You can have a server side proxy for authenticated and authorised users, with a rate limit.
UltimateEdge 3y ago
The replies suggest storing the API key on a backend which you control.
devit 3y ago
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.
kgeist 3y ago
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.
thewataccount 3y ago
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.
numpad0 3y ago
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.
- agentwiggles 3y ago
  Why is that dystopian? Sounds like the standard, good-idea architecture for an application that communicates with a paid 3rd party API.
- hagbarth 3y ago
  It's... pretty normal practice.
- GrinningFool 3y ago
  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.

by ncann 3y ago

speedgoose 3y ago

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

UltimateEdge 3y ago

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

devit 3y ago

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.

kgeist 3y ago

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.

thewataccount 3y ago

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.

numpad0 3y ago

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.

agentwiggles 3y ago
Why is that dystopian? Sounds like the standard, good-idea architecture for an application that communicates with a paid 3rd party API.
hagbarth 3y ago
It's... pretty normal practice.
GrinningFool 3y ago
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.