Generally speaking that is what OAuth should be used for with clearly defined scopes and insights in what apps are making use of the API through your account. Not an API key with full access and no limitations.
With openAI and other providers, I know you can limit the budget for a key, but that is still a pretty broad scope you are left with.
OAuth is nice when you're making an interactive in-browser SaaS. Sucks for just about any other application, in particular anything that may run headless.
Thankfully, OpenAI and the like offer actual APIs I can use for software and automation I write. And it is my right, both as a user and a developer, to let someone else write the software I'll use with my keys. It's up to me to decide if I trust that software, and suffer the consequences of a mistake. It's like the most basic way of using software, and I appreciate when I can use it like that, without having anyone insert themselves in the middle to help me stay "more secure".
Sure, but people are suggesting OpenAI and Anthropic should use OAuth instead of API keys. It hardly makes sense to provide both for the same functionality.
Also CORS is a PITA. Even for personal use, a browser is the most convenient environment to develop some helper tools and scripts, and it's also the only environment that - until now - could not be used with those APIs. The solution here definitely isn't moving from API keys to OAuth.
I don't think there's any reason to draw such a hard distinction between API keys and OAuth2 tokens. Either can be a subset of the other.
In a well-designed OAuth2 flow, the user should be able to select fine-grained permissions if they want to. You should be offering that same level of control for API keys. I don't see why they can't share almost all the same infrastructure. The main different is the API calls needed for OAuth2, but it's a huge value add.
You can still let people generate keys if they want to, but a well-implemented OAuth2 deployment is superior even in headless cases. Rather than having to click through the dashboard generating and copypasting keys, I can enter a short OAuth2 code in the CLI and be off to the races. Plus you get all the security benefits of token rotation, etc.
They don’t - which is a shame, I’d love to be able to bounce a user through an OAuth flow and then make API calls using their token such that their activity is billed to them directly.
Even using the client's keys it would be a good idea to give a disclaimer that their key may be stored (If that is the case) and can be accessible through nefarious means. People are very susceptible to phishing attempts etc. and this sort of business model (where you have the client supply the key and store it through the browser is a slippery slope.
From an application developer's perspective, the nice thing about using a passkey with a browser cookie is that you don't have to store anything sensitive. You're only guarding access to your own app with meaningless numbers. If your app doesn't store other sensitive data, the blast radius is small. There are still denial of service attacks to worry about where an attacker can use network or compute to run up your bill.
What are we guarding when building an app that uses a cloud API that costs money? Access to more compute resources. Probably a lot more than the app itself ever uses. It raises the stakes a bit. Still, in monetary terms, you're operating a vending machine that the user puts money into.
Maybe there could be some kind of protocol and workflow to securely buy a dollar of compute time from an AI vendor?
If they send some of the money to the app developer's account, it's starting to sound like an app store or micropayments system.
