Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloudlflare builds OAuth with Claude and publishes all the prompts

github.com

Post reply on HN
Print view View original

171–180 of 552 posts

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#171

Post by DaiPlusPlus »

EtienneK wrote: post #169

> This is a TypeScript library that implements the provider side of the OAuth 2.1 protocol with PKCE support. What is the "provider" side? OAuth 2.1 has no definition of a "provider". Is this for Clients? Resource Servers? Authorization Server? Quickly skimming the rest of the README it seems this is for creating a mix of a Client and a Resource Server, but I could be mistaken. > To emphasize, this is not "vibe coded…

> OAuth 2.1 has no definition of a "provider"

Strictly speaking, yes. But speaking of IDPs more broadly, it’s perfectly acceptable to refer to the authorisation-server as an auth-provider, especially in OIDC (which is OAuth, with extensions) where it’s explicitly called “OpenID provider” - so it’s natural for anyone well-versed in both to cross terminology like that.

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#173

Post by Denzel »

jsnell wrote: post #160
dingnuts wrote: post #139

Earlier quoted context omitted.

> Just the ability to speed up exploration and validation based on what a human tells it to do is already enormously useful, depending on how much you can speed up those things, and how accurate it can be. The big question is: is it useful enough to justify the cost when the VC subsidies go away? My phone recently offered me Gemini "now for free" and I thought "free for now, you mean. I better not get used to that. T…

Inference is actually quite cheap. Like, a highly competitive LLM can cost 1/25th of a search query. And it is not due to inference being subsidized by VC money. It's also getting cheaper all the time. Something like 1000x cheaper in the last two years at the same quality level, and there's not yet any sign of a plateau. So it'd be quite surprising if the only long-term business model turned out to be subscriptions.

Can you link to any sources that support your claim?

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#174

Post by steveklabnik »

qsort wrote: post #9
unshavedyak wrote: post #5

Yup. I'm more skeptic than pro-AI these days, but nonetheless i'm still trying to use AI in my workflows. I don't actually enjoy it, i generally find it difficult to use as i have more trouble explaining what i want than actually just doing it. However it seems clear that this is not going away and to some degree it's "the future". I suspect it's better to learn the new tools of my craft than to be caught unaware. Wi…

Probably unrelated to the broader discussion, but I don't think the "skeptic vs pro-AI" distinction even makes that much sense. For example, I usually come off as being relatively skeptic within the HN crowd, but I'm actually pushing for more usage at work. This kind of "opinion arbitrage" is common with new technologies.

One recent post I read about improving the discourse (which I seem to have lost the link...) agrees, but in a different way: adding a "capable vs not" axis. that is, "I believe AI is good enough to replace humans, and I am pro" is different than "I believe AI is good enough to replace humans, and I am against" and while "I believe AI is not good enough to replace humans, and I am pro" is a weird position to take, "I believe AI is not good enough to replace humans, and I am against."

These things are also not binary, they're a full grid of space.

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#175

Post by weinzierl »

"I thoughts LLMs were glorified Markov chain generators"

"the code actually looked pretty good. Not perfect, but I just told the AI to fix things, and it did. I was shocked."

These two views are by no means mutually exclusive. I find LLMs extremely useful and still believe they are glorified Markov generators.

The take away should be that that is all you need and humans likely are nothing more than that.

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#176

Post by kentonv »

EtienneK wrote: post #169

> This is a TypeScript library that implements the provider side of the OAuth 2.1 protocol with PKCE support. What is the "provider" side? OAuth 2.1 has no definition of a "provider". Is this for Clients? Resource Servers? Authorization Server? Quickly skimming the rest of the README it seems this is for creating a mix of a Client and a Resource Server, but I could be mistaken. > To emphasize, this is not "vibe coded…

This library helps implement both the resource server and authorization server. Most people understand these two things to be, collectively, the "provider" side of OAuth -- the service provider, who is providing an API that requires authorization. The intent when using this library is that you write one Worker that does both. This library has no use on the client side.

This is intended for building lightweight services quickly. Historically there has been no real need for "lightweight" OAuth providers -- if you were big enough that people wanted to connect to you using OAuth, you were not lightweight. MCP has sort of changed that as the "big" side of an MCP interaction is the client side (the LLM provider), whereas lots of people want to create all kinds of little MCP servers to do all kinds of little things. But MCP specifies OAuth as the authentication mechanism. So now people need to be able to implement OAuth from the provider side easily.

> Experience with the RFCs but have not been able to correctly name it.

These docs are written for people building MCP servers, most of whom only know they want to expose an API to AIs and have never read OAuth RFCs. They do not know or care about the difference between an authorization server and a resource server.

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#178

Post by smallnix »

weinzierl wrote: post #175

"I thoughts LLMs were glorified Markov chain generators" "the code actually looked pretty good. Not perfect, but I just told the AI to fix things, and it did. I was shocked." These two views are by no means mutually exclusive. I find LLMs extremely useful and still believe they are glorified Markov generators. The take away should be that that is all you need and humans likely are nothing more than that.

> humans likely are nothing more than that

Relevant post: https://news.ycombinator.com/item?id=44089156

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#179

Post by kentonv »

freedomben wrote: post #140
kentonv wrote: post #33

Earlier quoted context omitted.

(I'm the author of this library -- or, the guy who prompted the AI at least.) I absolutely would not vibe code an OAuth implementation! Or any other production code at Cloudflare. We've been using more AI internally, but made this rule very clear: the human engineer directing the AI must fully understand and take responsibility for any code which the AI has written. I do think vibe coding can be really useful in low-…

What tools did you use for the vibe coding an Android app? And was it able to do the UI stuff too? I've wanted to do this but am not sure how to get started. For example, should I generate a new app in Android Studio and then point Claude Code at it? Or can I ask Claude Code (or another agent) to start it from scratch? (in the past that did not work, but I'm curious if it's just a PEBKAC error)

I used Claude Code. I actually just asked it what tools I needed for a CLI-driven build, and it told me what to install (or even installed it for me in some cases). I basically didn't read any documentation, just asked Claude what I should do.

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#180

Post by throwaway314155 »

philipwhiuk wrote: post #109
kentonv wrote: post #105

Earlier quoted context omitted.

It took me a few days to build the library with AI. I estimate it would have taken a few weeks, maybe months to write by hand. That said, this is a pretty ideal use case: implementing a well-known standard on a well-known platform with a clear API spec. In my attempts to make changes to the Workers Runtime itself using AI, I've generally not felt like it saved much time. Though, people who don't know the codebase as…

> Though, people who don't know the codebase as well as I do have reported it helped them a lot. My problem I guess is that maybe this is just Dunning-Kruger esq. When you don't know what you don't know you get the impression it's smart. When you do, you think it's rubbish. Like when you see a media report on a subject you know about and you see it's inaccurate but then somehow still trust the media on a subject you'…

I think most of this just amounts to the same old good developers vs. bad developers situation that we've been in for decades.
Post reply on HN