Hello, I am developing an application in which users will be able to use their API key for operation. It is planned that the API key will be stored by the user in autofill or LocalStorage, and not on the server. My question is whether it is allowed for users to use their API key in this scenario? Is BYOK allowed?
Hi and welcome to the Developer Forum!
Bring your own key application are not strictly prohibited, but it is strongly suggested that users do not use their API keys outside of their own private infrastructure, regardless of where it is stored.
Developers should use their own API key and users should pay you for access. End users should not be using API keys, they are for developers.
1 Like
Is the API key being sent to you or directly to OpenAI?
One of these is “developing an end-user OpenAI application”.
The other is a deceptive facade of security where key capture and abuse is possible by multiple parties.
If a web application, the former can be turned into the latter by one web site keystroke.
It’s not even possible to “Send the API Key directly to OpenAI” in a web application due to CORS…
There are many past posts around this that claim it violates the TOS/Usage Policy, but from what I can tell, Open AI has updated their legal docs, and I’m unable to find the language where they explicitly restrict accept developer tokens.
You can read between the lines
- transferring keys
If you place an API key in an application, you are basically giving your account access to a third party
- preventing abuse
They don’t want to hear about how your key was stolen to make $500 worth of GPT-4 calls to make Chinese AI
- unspoken content policy
An API key used on a third-party product that uses jailbreak techniques to do undesired things (like “sexy talk with a waifu”) can be fingerprinted and get the API account banned.
I can sit here on a desktop machines and make API calls all day using nothing more than a properly formed authorization header. There’s more in play if you are getting other errors.
Ya, of course you can send the request directly to OpenAI on a “desktop application”. CORS policy is only enforced in client side code running browsers…
The request is about a desktop app which directly communicates with the OpenAI API. The end-user is supposed to get invited as a member to a team account and use their own API Key for this purpose, since there is no backend API service which can do that.
The token itself is stored with the (Eclipse) local store, which in turn can use Windows DAPI protection for secrects.
There is a regulation which means “do not deploy in mobile apps or clients” but I think the idea is that you dont ship your developer key in software packages. If the end users bring their own key, this is not covered by that policy.
In fact the rule “do not share use your own key” and “use a central backend” seems to be contradicting, so not using a backend seems like its not worse…?
Having said that, is there a OAuth Device secret or similar flow, so the user does not need to copy and paste api keys?
Refering to number 2 here: Best Practices for API Key Safety | OpenAI Help Center
You can develop standalone applications that take a user API key and then the user makes API calls direct to OpenAI with their own credentials or that stored in an environment variable.
It is then the users that are discouraged from ever putting their secrets into unknown software, or simply running any software that targets API users and their environment variables. There are campaigns that use such ploys to steal keys and empty accounts.
The way that you would administer a larger organization is the same as if you are developing subscription apps - the only client communication is between you and the client, using your own secrets, accounts, and your own API protocols. The communication to OpenAI using endpoint methods only happens on your edge server.
So there is no OAuth flow like for example VSCode is using with Github logins to get tokens to use CoPilot 
Is there maybe a Azure equivalent?
Azure also uses API keys for OpenAI services.
The OpenAI API is a developer backend, not a client portal that maintains your customers for you.
of course not, the question is if policy forbids multiplexing. If i have a tool in my company for ten employees, do i need a token for each of them or not?
My understanding is:
- keep your API tokens secure, this includes not distributing it in your code to external customers (funny enough using env vars is not very secure but i guess thats a generation problem
- dont “proxy” ai services to conflict with OpenAI business
- for local deployments of API keys use key-per user
When the number of keys that can be created in the organization is within the number of employees that need access, you can create a key for each employee, which will allow the (limited) usage tracking and also the ability to disable one person instead of a group of users. There is no technical reason why one API key cannot be used by many.
thats true, its not a technical question - in this case its about the various “dont share” policies and recommendedations in the OpenAI documents - but I guess its just worded for a different problem case.
Its our understanding that we can offer a desktop application which has a input field for storing a API key locally and will recommend the customer to get one key per user and check usage policies of their OpenAI contract.
Basically, the risk is very high of exposure to abuse the more widely API keys are distributed. A single key leaked on the internet to an adversary can have your account emptied quickly. Thus a secure backend that never actually gives API keys to users is highly-recommended. This can also perform moderations so you don’t get banned because someone made a porn bot on your dime.
The API has another system, where members can be invited to an organization. This allows the user to create their own API keys in their account, but the billing of the API keys can be assigned to an organization they belong to. Then you can cut off a member by removing them from the organization, while the user is otherwise free to create multiple keys that bill to you without limit.