Claude's API now supports CORS requests, enabling client-side applications • Hacker News Board

Re: Claude's API now supports CORS requests, enabling client-side applications

#131

Post by apitman » Fri, Aug 23, 2024, 4:47 PM UTC

afiodorov wrote: post #10

I love making web apps where users bring their own keys. This approach combines the best of both worlds: the convenience of distributing executable files and the benefits of open source. So far, I have developed two web apps: 1. A live transcription and translation app that uses microphone input. This is useful for watching proprietary content and facilitating communication. 2. An app that translates SRT subtitles in…

The UX could be so much better and more secure. This type of use case is a perfect fit for OAuth2.

Current UX:

1. User hits your app

2. You tell them to go to Anthropic and generate an API key. You'll probably need to give them instructions on how to do so, which will become outdated over time as Anthropic makes changes to their website.

3. User goes to Anthropic and generates an API key

4. User manually navigates back to your app and pastes the key

OAuth2 UX:

1. You redirect the user to Anthropic

2. The user approves your app getting access

3. Anthropic redirects the user back to you and your app starts working.

For the life of me I don't understand why orgs don't implement OAuth2 for basically everything. Yes it is more complicated on the developer side, but that's for good security reasons. And it isn't that bad, and well worth the moderate time investment.

Re: Claude's API now supports CORS requests, enabling client-side applications

#132

Post by apitman » Fri, Aug 23, 2024, 5:02 PM UTC

TeMPOraL wrote: post #126

creesch wrote: post #52

Earlier quoted context omitted.

Mate, the context is that Claude now supports CORS. We are talking about in-browser use.

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 f…

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.

Re: Claude's API now supports CORS requests, enabling client-side applications

#133

Post by spyspy » Fri, Aug 23, 2024, 5:14 PM UTC

apitman wrote: post #131

afiodorov wrote: post #10

I love making web apps where users bring their own keys. This approach combines the best of both worlds: the convenience of distributing executable files and the benefits of open source. So far, I have developed two web apps: 1. A live transcription and translation app that uses microphone input. This is useful for watching proprietary content and facilitating communication. 2. An app that translates SRT subtitles in…

The UX could be so much better and more secure. This type of use case is a perfect fit for OAuth2. Current UX: 1. User hits your app 2. You tell them to go to Anthropic and generate an API key. You'll probably need to give them instructions on how to do so, which will become outdated over time as Anthropic makes changes to their website. 3. User goes to Anthropic and generates an API key 4. User manually navigates ba…

Devs here often don’t even really understand JWT tokens as evidenced by the hundreds-of-comments deep arguments I’ve witnessed over them.

Re: Claude's API now supports CORS requests, enabling client-side applications

#134

Post by serjester » Fri, Aug 23, 2024, 5:20 PM UTC

afiodorov wrote: post #10

I love making web apps where users bring their own keys. This approach combines the best of both worlds: the convenience of distributing executable files and the benefits of open source. So far, I have developed two web apps: 1. A live transcription and translation app that uses microphone input. This is useful for watching proprietary content and facilitating communication. 2. An app that translates SRT subtitles in…

While this is nice, I don't think the dangers are discussed enough. A user has no guarantee their key isn't just being sent to some malicious third party. Normalizing this seems dangerous because it only takes a couple bad actors.

Sure you could try to get people to issue / delete keys every time they use an online app but it seems unlikely most users will do that.

Re: Claude's API now supports CORS requests, enabling client-side applications

#135

Post by 6510 » Fri, Aug 23, 2024, 5:20 PM UTC

afiodorov wrote: post #10

I love making web apps where users bring their own keys. This approach combines the best of both worlds: the convenience of distributing executable files and the benefits of open source. So far, I have developed two web apps: 1. A live transcription and translation app that uses microphone input. This is useful for watching proprietary content and facilitating communication. 2. An app that translates SRT subtitles in…

> A live transcription and translation app that uses microphone input. This is useful for watching proprietary content and facilitating communication.

It would be funny to transcribe someones speech, improve the grammar and play it back in their own voice.

Re: Claude's API now supports CORS requests, enabling client-side applications

#136

Post by apitman » Fri, Aug 23, 2024, 5:22 PM UTC

spyspy wrote: post #133

apitman wrote: post #131

Earlier quoted context omitted.

The UX could be so much better and more secure. This type of use case is a perfect fit for OAuth2. Current UX: 1. User hits your app 2. You tell them to go to Anthropic and generate an API key. You'll probably need to give them instructions on how to do so, which will become outdated over time as Anthropic makes changes to their website. 3. User goes to Anthropic and generates an API key 4. User manually navigates ba…

Devs here often don’t even really understand JWT tokens as evidenced by the hundreds-of-comments deep arguments I’ve witnessed over them.

JWTs are orthogonal to OAuth2. Tokens in OAuth2 are opaque to the client applications. JWTs are one way to do it, though with significant tradeoffs.

Re: Claude's API now supports CORS requests, enabling client-side applications

#137

Post by apitman » Fri, Aug 23, 2024, 5:23 PM UTC

saagarjha wrote: post #53

Web security noob here. Why does CORS even exist? The fact that a website can’t make a request to another website unless that domain likes it is kind of insane to me. Everyone in the comments here is going on about how maybe the user’s API key gets leaked by a malicious application or whatever but, like, when I write software that isn’t in the browser I can just send a request to anyone without restrictions and as fa…

CORS exists to keep us humble. The first time you think you understand it, your journey has only just begun.

Re: Claude's API now supports CORS requests, enabling client-side applications

#138

Post by LeoPanthera » Fri, Aug 23, 2024, 5:26 PM UTC

MeetingsBrowser wrote: post #115

How are people using the Claude API as individuals? Officially, individuals are not allowed to use the API. https://support.anthropic.com/en/articles/8987200-can-i-use-...

Huh! That's a surprise. Especially as OpenAI has no problem with it.

Re: Claude's API now supports CORS requests, enabling client-side applications

#139

Post by 6510 » Fri, Aug 23, 2024, 5:34 PM UTC

serjester wrote: post #134

afiodorov wrote: post #10

I love making web apps where users bring their own keys. This approach combines the best of both worlds: the convenience of distributing executable files and the benefits of open source. So far, I have developed two web apps: 1. A live transcription and translation app that uses microphone input. This is useful for watching proprietary content and facilitating communication. 2. An app that translates SRT subtitles in…

While this is nice, I don't think the dangers are discussed enough. A user has no guarantee their key isn't just being sent to some malicious third party. Normalizing this seems dangerous because it only takes a couple bad actors. Sure you could try to get people to issue / delete keys every time they use an online app but it seems unlikely most users will do that.

The browser doesn't need to facilitate this.

They could generate an application specific key. Could do that every time one uses the application by forwarding though the website issuing the key and back.

I want government id to work like that. You authorize the website on the .gov then the website only gets a key, no further information. The only thing to knows about the key is that each citizen gets to generate one key for each [registered] domain.

Re: Claude's API now supports CORS requests, enabling client-side applications

#140

Post by hagope » Fri, Aug 23, 2024, 5:36 PM UTC

Anthropic and all the AI vendors need to implement "Login with ___" allowing users to trust sites to use their own AI resources, similar to how Dropbox allows 3rd party access to the User's storage. Most users don't want to bother with generating and loading API keys, nor can they manage it safely.