El suposat forat de 3.000 milions d’OpenAI: què fa realment OpenAI OAuth

This button gives you free AI from OpenAI in any app, and it can literally cost OpenAI billions of dollars per year, which is exactly why I open-sourced it so that by the end of this video, you too will be able to instantly get free OpenAI API, and not only that, due to the way it works, OpenAI can do nothing to stop me. Let me explain. If you want to use OpenAI's AI in any app, you need an API key with every request costing [music] money. In fact, OpenAI makes nearly $3 billion off their API each year. But, there's an obvious exception. You can use ChatGPT and other products by OpenAI themselves for free. And with a subscription, you can use far more AI than you can with the same cost in API. The reason, of course, is that they lure you in and trap you into using their product. But, ironically, this pricing difference between a ChatGPT account and API isn't quite so open, especially given the fact that it's the same [music] compute and

exact same cost for OpenAI to run a model in their product or with an API key. So, I always wondered, what [music] if we could turn your ChatGPT account into an API that you can use anywhere? A single sign-in with ChatGPT button [music] that would become OpenAI's billion-dollar button that they definitely don't want you to have. Now, the obvious solution to achieve this is to reverse engineer chat.openai.com, where you can essentially access free AI with your account. You would have to figure out how they store your login credentials and then intercept network requests to see how those credentials are used to authenticate the internal ChatGPT endpoint that the website uses. I would know this because over 3 years ago, I had to reverse-engineer Google AI SDK that used this path before Google even had an API. But, from that, I learned that not only are those [music] credentials unstable, meaning that you would have to constantly update them

manually, the internal ChatGPT endpoint is also highly abstracted, meaning that you can't do things like add custom tools or get direct access to the transcript. But, ChatGPT is just one of OpenAI's products. Looking at the selection of all the other products that we can approach and try to reverse-engineer to achieve our goal, the choice becomes obvious: Codex CLI. Like other products, it allows you to log in with your ChatGPT account to use AI. But, unlike other products, it's open source, which means that not only could we easily reverse engineer and replicate their authentication pattern, their API also has to be stable, documented, and feature-rich because the same maintain shipping product OpenAI is constantly updating. Exactly the type of API that we would want to reverse engineer. But, the best part about this is that OpenAI can't block access on this Codex API without breaking Codex itself, meaning that they can't stop you

on a technical level from using this endpoint. And even on a practical level, OpenAI has essentially said multiple times that they are okay with using alternate harnesses with a Codex subscription. And this is simply a generalization of that. So, we're good to dig in. The way it works is simple. Codex stores a special set of OAuth-based credentials, which you use to authenticate your requests to an internal endpoint instead of an API key. Since we can simply look at the code, it's trivial to find the exact logic to use those credentials to make requests. We could then build a bridge from that internal endpoint to a standard OpenAI API interface. And while there were some limitations with the Codex internal API, we could hide many of these things within our bridge. For example, Codex's endpoint requires special headers and identifiers. Our bridge can inject those for you. Codex also only supports streaming requests. So, our bridge can

stream under the hood and return a non-streaming request if you need it. But, of course, there were other limitations that we simply couldn't work around, such as the fact that even though this works on a free plan, you are still subject to rate limits, or the fact that the models you have access to also varies based on your plan. Nonetheless, just like that, OpenAI themselves had essentially just handed us the ability to turn a ChatGPT account into a free API key. And believe it or not, you can literally try this out right now by typing NPX OpenAI-OAuth into your terminal. It'll take your free or paid ChatGPT account, and using my specially designed bridge, turn it into a free OpenAI API. But, even with that, we're only halfway done because so far, we've only handled using credentials we already have on the user's device. Where it gets really interesting is getting those credentials in the first place, which can enable users beyond developers

with Code X CLI to replace their API keys. But to understand why this is so difficult and significant, we have to start back at Code X CLI, reverse engineering how users sign in. It's a pretty standard OAuth flow. When a client device begins sign in, it starts listening at a special localhost port, 1455. Then it sends you to OpenAI's website, on which you can log in to your account. Most importantly, when you're done, sends those credentials back to the localhost [music] 1455 port from the beginning, so that the client device that initialized the request can use those credentials to make requests just like we have done. Since we have Code X's source, it's trivial to figure out the special OAuth URL needed to initialize the authentication and replicate it locally on the user's computer. We simply have to start a service at 1455, and the rest is straightforward. But now, let's take it a step further. How can we make the sign

in flow work in even a browser, so that any user, anywhere, can instantly log in with their ChatGPT account to any website? Something that would allow not only developers, but users all around the world to [music] ditch API keys altogether. The issue though is that OpenAI's OAuth flow only returns credentials to localhost 1455, and a normal browser tab can't read localhost, much less open a service on a port to read those credentials. So natural next step is to have a server on the cloud, which has access to its own localhost and can handle the OAuth flow there. But things quickly fall apart. First, the server doesn't have your OpenAI account. So you have to use OpenAI's device code authentication, which allows you to authenticate into a remote device using a one-time code. But this also requires you to turn on a setting in your ChatGPT account, which is rather annoying and feels like a loss of trust. And that aside, if you just think about it, this

is essentially giving away your ChatGPT account to some random third-party server, which I personally would never want to do. So, seems like we are at a dead end. [music] An external server is dangerous, and browser tabs can't interact with localhost unless we accept one trade-off. [music] Browser tabs can't interact with localhost. But, what about the browser itself? You see, browser extensions, which can tap into the capability of the browser itself, can open and thus read existing localhost websites. But, even an extension can't create a service that runs on a localhost 1455 to await credentials. However, what if we don't need to? You see, the purpose of that server is to capture credentials from a remote service locally. But, when OpenAI makes the request to localhost, that request itself already has the authentication data that we need. [music] So, all our extension has to do is to intercept that request and

redirect the credentials back to the website that is trying to sign in, instead of ever having to deal with localhost directly. And with a completely open source and local browser extension, we can do this directly between your browser and OpenAI. No credentials leave your system during the sign-in flow, and no need to change any ChatGPT settings. And to make it easy, [music] the first time you use the sign-in flow, it takes you directly to the Chrome Web Store so that there is no friction. Now, we can store these credentials locally, encrypted in browser storage at rest, only used to make [music] API requests through the same bridge that we talked about minutes ago, completing the circuit. And just like that, we've just managed to authenticate an OpenAI account to make requests as if it were an API key. This is OpenAI's [music] billion-dollar button, and I just made it open source. Getting started is simple. With the set

of OpenAI OAuth libraries, you can set up the sign-in button with just one React component and connect it to any OpenAI compatible SDK, like the Vercel AI SDK. My vision is that frontier intelligence is accessible to more people, [music] and not just in apps that the labs want you to use. With sign-in with ChatGPT, that is easier than ever. If you want to try it out, a demo sign-in with ChatGPT is available on Vercel at openai-oauth.vercel.app. [music] And you can always get started locally by just running MPX openai-oauth. Feel free to contribute or leave any feedback or issues at github.com/evanjodav/openai-oauth. If you integrate OpenAI OAuth into any apps, please share your creation on X and tag me @EvanJoeDev. I'd be happy to see what everyone is building. Usage of OpenAI OAuth is still subject to OpenAI's terms of use and other user agreements. I'll see you guys next time. Peace.