[PaulWaldman]

>the only solution to safely not leak your API key is to have your app only communicate with a backend you own and call the openAI from there.

Don't you still have the same problem? Your backend would also require a key for the client to communicate, which would still be embedded in the client binary.

[survirtual]

No.

You go through traditional auth channels (username / password) or you generate a key per app user to talk with your backend.

Or, you keep the backend you control open and implement controls to combat abuse, such as rate limiting and ip blacklisting.

Whatever chosen, the objective is to protect your API key and make sure the application is being used according to its purpose.

An API key directly to openAI allows for any use under the sun — botnets, new prompts, etc., and can drain money, put your account in bad standing, or even get you in (potentially serious) legal trouble. Using your own backend, you can do things like hit the openAI moderation endpoint, inject the correct prompts into whatever you’re sending to openAI, etc.

The main thing is you have a limited API specific to your app offering which significantly lowers the damage possible. You absolutely always want to give users the least privilege necessary for whatever use cases being provided for — this protects both you and your users.

[counttheforks]

You have a different problem. You can handle the authentication, and blacklisting, on your side. That's harder to do when the clients communicate with OpenAI or another third party directly, while incurring charges that you have to pay for.

[CuriouslyC]

No, your proxy site can have a login flow or some other unique id process that is per client like any web app.

[Gravyness]

Yes, but you could negotiate a token with each user on startup and if someone starts abusing your service you can block that access (perhaps automatically) or know who it is by authenticating the user.