Authentication options on behalf of a user

Thanks @PaulBellow! I was looking for a similar post earlier but could not find anything

1 Like

@RonaldGRuckus Yeah, I’m very hesitant to share my own key. I know the OAuth2.0 framework supports flows to send requests on behalf of a user. I’ve used it through Microsoft in the past. I guess I was hoping some solution already existed that I didn’t know about. :laughing:

I was just reading through the post linked above, and I’m wondering if this response was talking about something similar.

1 Like

No. Not at this time.

The OpenAI API is only accessible using an API key and there are no published plans that anyone knows of for OpenAI to change this policy and authentication method.

Hope this helps.


1 Like

Thanks for bringing this up. I hope OpenAI will implement something similar as soon as possible.

Both the ChatGPT and the OpenAI APIs would benefit from an oAuth 2.0 Consent setup. From developer perspective; onboarding becomes more seamless. From user perspective, we would have the confidence that we can revoke consent / inspect usage per client.

I would even go further and say this should be the suggested way that third party applications integrate with OpenAI. As a user, I am already paying for an OpenAI subscription. Why can’t I utilize the same account with different websites / tools?


I couldn’t agree more. I have developed an app for learning. I would like to have the content generated for the users tailored with the OpenAI API. I don’t think it’s safe or trustworthy to enter an API key in my own UI. If I use my API key I have to build a payment model for it into the app, which would be beyond the effort. An OAuth authentication like Facebook, Google, etc. where the user is redirected to the OpenAI page to enter his credentials would be fantastic and actually a must.

Translated with DeepL Translate: The world's most accurate translator (free version)

1 Like

I have an app in development where the user enters their OpenAI API key, I verify it with a call to the models api endpoint, then store it in the database, and make API requests with it from the backend on their behalf when they take certain actions in the front end app. This works just fine. You can leave the organization field of the npm package’s Configuration object empty and only supply the api key.

UPDATE: guess I can’t roll it out this way. Here’s the canonical post:

Would have been good if the docs were clearer on this point, and if there was an OAuth or other method for doing this, because otherwise, no one can write an app that users can access for free.

This is a violation of OpenAI’s policies and can get everyone permanently banned.


Agree with elmstedt’s here, the sharing of API keys are against the terms of service.

I’ll recommend the following help page for more information on best practices for API key safety

I am doing all calls from the backend. Nowhere in that document does it say that an app can’t be set up thus way. I’ve been building software since the early 80’s, i I understand how to protect an API key.

You might have missed it, let me paste the relevant section for you here:

  1. Always use a unique API key for each team member on your account.
    An API key is a unique code that identifies your requests to the API. Your API key is intended to be used by you. The sharing of API keys is against the Terms of Use.

I’ve highlighted the relevant parts in bold so they’re a bit easier to spot.

Hope that helps :laughing:

It is not sharing an API key if only you use it. In this app you are the only user of your API key. I think this line is more like people sharing their Netflix passwords with family and friends, which makes way more sense as an activity to curb.

It is unfortunately sharing of API keys since the user is sharing their API key with you, you also mention this yourself

You’re also storing said API key for later use. All users who interact with your app is at risk of getting banned from using openAI’s services.

I do not say the user shares their key. I say they enter it, and I store it and make calls on their behalf. That is different from sharing. Sharing is where I give you my key and you use it for whatever you like as if it were your own.

My app is ages from production, I can refactor it to use my own api key if need be. But it’s not unsafe to build an app this way and it’s an onus for devs because you have to build a system to meter usage and charge users for access. It’s a huge extra piece that means you can’t build an app that users can access for free. It’s absurd.

That’s unfortunately what sharing of API keys means, but I understand that you have monetary interest in understanding it otherwise.

This is the developer community forum, the friendly people you meet here, are not employed by OpenAI, and has no say in how OpenAI’s policies are written.

I’d recommend that you follow your own advice here:

But remember there’s other options, you could also upload it to GitHub so people can run it themselves.

1 Like

He later goes on to clarify that if the key remains locally on the user’s machine that would be acceptable.

1 Like

That means you can’t build an app that forces users to give up their security by transferring their credentials to an untrusted third party with unknown security or possible nefarious purposes, where their use is not just not free, but can expose them to bad actors that would rack up massive fee abuse with use cases that would cause account termination.

Not putting API keys into bring-your-own-key applications that make requests on your behalf is the exact clarifying language that needs to be made for users. On the API key screen, imagine for those needing common sense: “This key is for your own locally-controlled software, not for putting into some AI waifu sex chat site.”

That’s true. In related news, Chrome is phasing out third party cookies, so exactly how implementation will work in the future isn’t clear. The APIs, they are a changin’.

Well, again, as has already been said, BYOK isn’t really what OpenAI has in mind for their services.

API keys are for developers—not consumers—so the best path forward is to set up a billing system and use your own key.

Why wouldn’t you just charge your own fee and make the calls using your own secure line with your own API keys?

If you don’t have a tracking system for usage I would never want to put any of my credentials or keys on it.

I don’t understand this mentality. It’s like building a house and not putting any gas meters because … What? You don’t want to? If you are a good dev your work will be paid for. Spend more effort!

There’s two people in the digital world. Those who have been hacked, and those that don’t know. Extreme, but hopefully you get the point. If you aren’t measuring anything you are an easy target

If you decide to “host” the keys I hope you have enough money to pay your lawyers. You’re taking on an incredible amount of risk for no reason, at the expense of your users.

To me that’s just bad business.

I’ve already refactored the app to only use my own key set securely via environment vars on the backend.

I think it’s possible that there are some assumptions being made about the potential slapdashedness going on with my implementation. This is an app meant primarily for me personally. I want to allow extremely gradual expansion only by working directly with small cohorts of hand-picked users. I just didn’t want to build a billing and metering system for this mostly experimental collaboration tool IMMEDIATELY. It isn’t for everyone in the world to access tomorrow or anytime in the near future.

1 Like