11 ms·
A look at Cloudflare's AI-coded OAuth library
- CuriouslyC 1y agoMostly a good writeup, but I think there's some serious shifting the goalposts of what "vibe coded" means in a disingenuous way towards the end: 'Yes, this does come across as a bit “vibe-coded”, despite what the README says, but so does a lot of code I see written by humans. LLM or not, we have to give a shit.' If what most people do is "vibe coding" in general, the current definition of vibe coding is essentially meaningless. Instead, the author is making the distinction between "interim workable" and "stainless/battle tested" which is another dimension of code entirely. To describe that as vibe coding causes me to view the author's intent with suspicion.
- croes 1y agoIsn’t vibe coding just C&P from AI instead of Stack Overflow? I read it as: done by AI but not checked by humans.
- ranguna 1y agoYep I see it like that as well, code with 0 or very close to 0 interactions from humans. Anyone who wants to change that meaning is not serious.
- techpression 1y agoI find ”vibe coding” to be one of the, if not the, concepts in this business to lose its meaning the fastest. Similar to how everything all of a sudden was ”cloud” now everything is ”vibe coded”, even though reading the original tweet really narrows it down thoroughly.
- dimitri-vs 1y agoIMO it's pretty clear what vibe coding is: you don't look at the code, only the results. If you're making judgement on the code, it's not vibe coding.
- keybored 1y agoViral marketing campaign term losing its meaning makes sense.
- simonw 1y agoHow do you define vibe coding?
- SiempreViernes 1y agoA very good piece that clearly illustrates one of the dangers with LLS's: responsibility for code quality is blindly offloaded on the automatic system > There are some tests, and they are OK, but they are woefully inadequate for what I would expect of a critical auth service. Testing every MUST and MUST NOT in the spec is a bare minimum, not to mention as many abuse cases as you can think of, but none of that is here from what I can see: just basic functionality tests. and > There are some odd choices in the code, and things that lead me to believe that the people involved are not actually familiar with the OAuth specs at all. For example, this commit adds support for public clients, but does so by implementing the deprecated “implicit” grant (removed in OAuth 2.1). As Madden concludes "LLM or not, we have to give a shit."
- JimDabell 1y ago> A very good piece that clearly illustrates one of the dangers with LLS's: responsibility for code quality is blindly offloaded on the automatic system It does not illustrate that at all. > Claude's output was thoroughly reviewed by Cloudflare engineers with careful attention paid to security and compliance with standards. > To emphasize, *this is not "vibe coded"*. Every line was thoroughly reviewed and cross-referenced with relevant RFCs, by security experts with previous experience with those RFCs. — https://github.com/cloudflare/workers-oauth-provider https://github.com/cloudflare/workers-oauth-provider The humans who worked on it very, very clearly took responsibility for code quality. That they didn’t get it 100% right does not mean that they “blindly offloaded responsibility”. Perhaps you can level that accusation at other people doing different things, but Cloudflare explicitly placed the responsibility for this on the humans.
- crashabr 1y agoStudies have shown that the more people use automated systems, the more they start to trust them, leaving to oversight. It's called [automation bias](https://en.m.wikipedia.org/wiki/Automation_bias https://en.m.wikipedia.org/wiki/Automation_bias). If a Cloudflare security engineer ends up missing the use of a deprecated functionality during a public experiment where they know they'll face very intense scrutiny, what will happen down the line, when llm use is normalized in security contexts?
- djoldman 1y ago> At ForgeRock, we had hundreds of security bugs in our OAuth implementation, and that was despite having 100s of thousands of automated tests run on every commit, threat modelling, top-flight SAST/DAST, and extremely careful security review by experts. Wow. Anecdotally it's my understanding that OAuth is ... tricky ... but wow. Some would say it's a dumpster fire. I've never read the spec or implemented it.
- bandoti 1y agoHonestly, new code always has bugs though. That’s pretty much a guarantee—especially if it’s somewhat complex. That’s why companies go for things that are “battle tested” like vibe coding. ;) Joke aside—I like how Anthropic is using their own product in a pragmatic fashion. I’m wondering if they’ll use it for their MCP authentication API.
- stuaxo 1y agoThe times I've been involved with implementations it's been really horrible.
- jajko 1y agoHundreds of thousands of tests? That sounds like quantity > quality or outright llm-generated ones, who even maintains them?
- nmadden 1y agoThis was before LLMs. It was a combination of unit and end-to-end tests and tests written to comprehensively test every combination of parameters (eg test this security property holds for every single JWT algorithm we support etc). Also bear in mind that the product did a lot more than just OAuth.
- jofzar 1y agoOauth is so annoying, there is so much niche to it.
- kcatskcolbdi 1y agoReally interesting breakdown. What jumped out to me wasn’t just the bugs (CORS wide open, incorrect Basic auth, weak token randomness), but how much the human devs seemed to lean on Claude’s output even when it was clearly offbase. That “implicit grant for public clients” bit is wild; it’s deprecated in OAuth 2.1, and Claude just tossed it in like it was fine, and then it stuck.
- deleted 1y ago[deleted]
- kentonv 1y agoI put in the implicit grant because someone requested it. I had it flagged off by default because it's deprecated.
- HocusLocus 1y agoI suggest they freeze a branch of it, then spawn some AIs to introduce and attempt to hide vulnerabilities, and another to spot and fix them. Every commit is a move, and try to model the human evolution of chess.
- sdan 1y ago> Another hint that this is not written by people familiar with OAuth is that they have implemented Basic auth support incorrectly. so tldr most of the issue the author has is against the person who made the library is the design not the implementation?
- belter 1y ago"...A more serious bug is that the code that generates token IDs is not sound: it generates biased output. This is a classic bug when people naively try to generate random strings, and the LLM spat it out in the very first commit as far as I can see. I don’t think it’s exploitable: it reduces the entropy of the tokens, but not far enough to be brute-forceable. But it somewhat gives the lie to the idea that experienced security professionals reviewed every line of AI-generated code...." In the Github repo Cloudflare says: "...Claude's output was thoroughly reviewed by Cloudflare engineers with careful attention paid to security and compliance with standards..." My conclusion is that as a development team, they learned little since 2017: https://news.ycombinator.com/item?id=13718752 https://news.ycombinator.com/item?id=13718752
- chrismorgan 1y agoAdmittedly I have done some cryptographic string generation based on different alphabet sizes and characteristics a few years ago, which is pretty specifically relevant, and I’m competent at cryptographic and security concerns for a layman, but I certainly hope security reviewers will be more skilled at these things than me. I’m very confident I would have noticed this bias in a first pass of reviewing the code. The very first thing you do in a security review is look at where you use `crypto`, what its inputs are, and what you do with its outputs, very carefully. On seeing that %, I would have checked characters.length and found it to be 62, not a factor of 256; so you need to mess around with base conversion, or change the alphabet, or some other such trick. This bothers me and makes me lose confidence in the review performed.
- thegeomaster 1y agoBut... is it a real problem? As the author says, the entropy reduction is tiny.
- yusina 1y agoIt shows carelessness or incompetence or a combination thereof which extend to the entire code base.
- afro88 1y ago> What this interaction shows is how much knowledge you need to bring when you interact with an LLM. The “one big flaw” Claude produced in the middle would probably not have been spotted by someone less experienced with crypto code than this engineer obviously is. And likewise, many people would probably not have questioned the weird choice to move to PBKDF2 as a response For me this is the key takeaway. You gain proper efficiency using LLMs when you are a competent reviewer, and for lack of a better word, leader. If you don't know the subject matter as well as the LLM, you better be doing something non-critical, or have the time to not trust it and verify everything.
- donatj 1y agoMy question is kind of in this brave new world, where do the domain experts come from? Whose going to know this stuff?
- mock-possum 1y agoSame place the previous generation came from - college courses, DIY hackers, and learn-on-the-job training and apprenticeships. Why would that change?
- maegul 1y agoThis, for me, has been the question since the beginning. I’m yet to see anyone talk/think about the issue head on too. And whenever I’ve asked someone about it, they’ve not had any substantial thoughts.
- PUSH_AX 1y agoEngineers will still exist and people will vibe code all kinds of things into existence. Some will break in spectacular ways, some of those projects will die, some will hire a real engineer to fix things. I cannot see us living in a world of ignorance where there are literally zero engineers and no one on the planet understands what's been generated. Weirdly we could end up in a place where engineering skills are niche and extremely lucrative.
- aiono 1y agoI agree with the last paragraph about doing this yourself. Humans have tendency to take shortcuts while thinking. If you see something resembling what you expect for the end product you will be much less critical of it. The looks/aesthetics matter a lot on finding problems with in a piece of code you are reading. You can verify this by injecting bugs in your code changes and see if reviewers can find them. On the other hand, when you have to write something yourself you drop down to slow and thinking state where you will pay attention to details a lot more. This means that you will catch bugs you wouldn't otherwise think of. That's why people recommend writing toy versions of the tools you are using because writing yourself teaches a lot better than just reading materials about it. This is related to know our cognition works.
- kentonv 1y agoI agree that most code reviewers are pretty bad at spotting subtle bugs in code that looks good superficially. I have a lot of experience reviewing code -- more than I ever really wanted. It has... turned me cynical and bitter, to the point that I never believe anything is right, no matter who wrote it or how nice it looks, because I've seen so many ways things can go wrong. So I tend to review every line, simulate it in my head, and catch things. I kind of hate it, because it takes so long for me to be comfortable approving anything, and my reviewees hate it too, so they tend to avoid sending things to me. I think I agree that if I'd written the code by hand, it would be less likely to have bugs. Maybe. I'm not sure, because I've been known to author some pretty dumb bugs of my own. But yes, total Kenton brain cycles spent on each line would be higher, certainly. On the other hand, though, I probably would not have been the one to write this library. I just have too much on my plate (including all those reviews). So it probably would have been passed off to a more junior engineer, and I would have reviewed their work. Would I have been more or less critical? Hard to say. But one thing I definitely disagree with is the idea that humans would have produced bug-free code. I've seen way too many bugs in my time to take that seriously. Hate to say it but most of the bugs I saw Claude produce are mistakes I'd totally expect an average human engineer could make. Aside, since I know some people are thinking it: At this time, I do not believe LLM use will "replace" any human engineers at Cloudflare. Our hiring of humans is not determined by how much stuff we have to do, because we basically have infinite stuff we want to do. The limiting factor is what we have budget for. If each human becomes more productive due to LLM use, and this leads to faster revenue growth, this likely allows us to hire more people, not fewer. (Disclaimer: As with all of my comments, this is my own opinion / observation, not an official company position.)
- jstummbillig 1y agoNote that this has very little to do with AI assisted coding; the authors of the library explicitly approved/vetted the code. So this comes down to different coders having different thoughts about what constitutes good and bad code, with some flaunting of credentials to support POVs, and nothing about that is particularly new.
- add-sub-mul-div 1y agoThe whole point of this is that people will generally put the least effort into work as they think they can get away with, and LLMs will accelerate that force. This is the future of how code will be "vetted". It's not important whose responsbility led to mistakes, it's important to understand we're creating a responsbility gap.
- ape4 1y agoThe article says there aren't too many useless comments but the code has: // Get the Origin header from the request const origin = request.headers.get('Origin');
- slashdev 1y agoThose kinds of comments are a big LLM giveaway, I always remove them, not to hide that an LLM was used, but because they add nothing.
- lucas_codes 1y agoPlus you just know in a few months they are going to be stale and reference code that has changed. I have even seen this happen with colleagues using llms between commits on a single pr.
- kissgyorgy 1y agoI also noticed Claude likes writing useless redundant comments like this A LOT.
- jallbrit 1y agoIMO, this is much better than the status quo. Most programmers are terrible about writing clean code with good comments. I would much prefer this style over unreadable mess (especially if it’s a language/framework I’m not comfortable with). But of course, it’s not an either-or. Ideally, I agree LLMs would provide slightly fewer comments.
- spenczar5 1y agoOf course, these are awful for a human. But I wonder if they're actually helpful for the LLM when it's reading code. It means each line of behavior is written in two ways: human language and code. Maybe that rosetta stone helps it confidently proceed in understanding, at the cost of tokens. All speculation, but I'd be curious to see it evaluated - does the LLM do better edits on egregiously commented code?
- keybored 1y agoOh another one,[1] cautious somewhat-skeptic edition. [1] https://news.ycombinator.com/item?id=44205697 https://news.ycombinator.com/item?id=44205697
- dweekly 1y agoAn approach I don't see discussed here is having different agents using different models critique architecture and test coverage and author tests to vet the other model's work, including reviewing commits. Certainly no replacement for human in the loop but it will catch a lot of goofy "you said to only check in when all the tests pass so I disabled testing because I couldn't figure out how to fix the tests".
- epolanski 1y agoPart of me this "written by LLM" has been a way to get attention on the codebase and plenty of free reviews by domain expert skeptics, among the other goals (pushing AI efficiency to investors, experimenting, etc).
- kentonv 1y agoFree reviews by domain experts are great. I didn't think of that, though. I didn't have an agenda here, I just put the note in the readme about it being LLM-generated only because I thought it was interesting.
- sarchertech 1y agoI just finished writing a Kafka consumer to migrate data with heavy AI help. This was basically best case a scenario for AI. It’s throw away greenfield code in a language I know pretty well (go) but haven’t used daily in a decade. For complicated reasons the whole database is coming through on 1 topic, so I’m doing some fairly complicated parallelization to squeeze out enough performance. I’d say overall the AI was close to a 2x speed up. It mostly saved me time when I forgot the go syntax for something vs looking it up. However, there were at least 4 subtle bugs (and many more unsubtle ones) that I think anyone who wasn’t very familiar with Kafka or multithreaded programming would have pushed to prod. As it is, they took me a while to uncover. On larger longer lived codebases, I’ve seen something closer to a 10-20% improvement. All of this is using the latest models. Overall this is at best the kind of productivity boost we got from moving to memory managed languages. Definitely not something that is going to replace engineers with PMs vibe coding anytime soon (based on rate of change I’ve seen over the last 3 years). My real worry is that this is going to make mid level technical tornadoes, who in my experience are the most damaging kind of programmer, 10x as productive because they won’t know how to spot or care about stopping subtle bugs. I don’t see how senior and staff engineers are going to be able to keep up with the inevitable flood of reviews. I also worry about the junior to senior pipeline in a world where it’s even easier to get something up that mostly works—we already have this problem today with copy paste programmers, but we’ve just make copy paste programming even easier. I think the market will eventually sort this all out, but I worry that it could take decades.
- awfulneutral 1y agoYeah, the AI-generated bugs are really insidious. I also pushed a couple subtle bugs in some multi-threaded code I had AI write, because I didn't think it through enough. Reviews and tests don't replace the level of scrutiny something gets when it's hand-written. For now, you have to be really careful with what you let AI write, and make sure any bugs will be low impact since there will probably be more than usual.
- skeeter2020 1y ago> I’ve seen something closer to a 10-20% improvement. The seems to match my experience in "important" work too; a real increase but not essentially changing the essence of software development. Brook's "No Silver Bullet" strikes again...
- roxolotl 1y ago> Many of these same mistakes can be found in popular Stack Overflow answers, which is probably where Claude learnt them from too. This is what keeps me up at night. Not that security holes will inevitably be introduced, or that the models will make mistakes, but that the knowledge and information we have as a society is basically going to get frozen in time to what was popular on the internet before LLMs.
- tuxone 1y ago> This is what keeps me up at night. Same here. For some of the services I pay, say the e-mail provider, the fact that they openly deny using LLMs for coding would be a plus for me.
- menzoic 1y agoLLMs are like power tools. You still need to understand the architecture, do the right measurements, and apply the right screw to the right spot.
- OutOfHere 1y agoThis is why I have multiple LLMS review and critique my specifications document, iteratively and repeatedly so, before I have my preferred LLM code it for me. I address all important points of feedback in the specifications document. To do this iteratively and repeatedly until there are no interesting points is crucial. This really fixes 80% of the expertise issues. Moreover, after developing the code, I have multiple LLMs critique the code, file by file, or even method by method. When I say multiple, I mean a non-reasoning one, a reasoning large one, and a next-gen reasoning small one, preferably by multiple vendors.
- kentonv 1y agoHi, I'm the author of the library. (Or at least, the author of the prompts that generated it.) > I’m also an expert in OAuth I'll admin I think Neil is significantly more of an expert than me, so I'm delighted he took a pass at reviewing the code! :) I'd like to respond to a couple of the points though. > The first thing that stuck out for me was what I like to call “YOLO CORS”, and is not that unusual to see: setting CORS headers that effectively disable the same origin policy almost entirely for all origins: I am aware that "YOLO CORS" is a common novice mistake, but that is not what is happening here. These CORS settings were carefully considered. We disable the CORS headers specifically for the OAuth API (token exchange, client registration) endpoints and for the API endpoints that are protected by OAuth bearer tokens. This is valid because none of these endpoints are authorized by browser credentials (e.g. cookies). The purpose of CORS is to make sure that a malicious website cannot exercise your credentials against some other website by sending a request to it and expecting the browser to add your cookies to that request. These endpoints, however, do not use browser credentials for authentication. Or to put in another way, the endpoints which have open CORS headers are either control endpoints which are intentionally open to the world, or they are API endpoints which are protected by an OAuth bearer token. Bearer tokens must be added explicitly by the client; the browser never adds one automatically. So, in order to receive a bearer token, the client must have been explicitly authorized by the user to access the service. CORS isn't protecting anything in this case; it's just getting in the way. (Another purpose of CORS is to protect confidentiality of resources which are not available on the public internet. For example, you might have web servers on your local network which lack any authorization, or you might unwisely use a server which authorizes you based on IP address. Again, this is not a concern here since the endpoints in question don't provide anything interesting unless the user has explicitly authorized the client.) Aside: Long ago I was actually involved in an argument with the CORS spec authors, arguing that the whole spec should be thrown away and replaced with something that explicitly recognizes bearer tokens as the right way to do any cross-origin communications. It is almost never safe to open CORS on endpoints that use browser credentials for auth, but it is almost always safe to open it on endpoints that use bearer tokens. If we'd just recognized and embraced that all along I think it would have saved a lot of confusion and frustration. Oh well. > A more serious bug is that the code that generates token IDs is not sound: it generates biased output. I disagree that this is a "serious" bug. The tokens clearly have enough entropy in them to be secure (and the author admits this). Yes, they could pack more entry per byte. I noticed this when reviewing the code, but at the time decided: 1. It's secure as-is, just not maximally efficient. 2. We can change the algorithm freely in the future. There is not backwards-compatibility concern. So, I punted. Though if I'd known this code was going to get 100x more review than anything I've ever written before, I probably would have fixed it... :) > according to the commit history, there were 21 commits directly to main on the first day from one developer, no sign of any code review at all Please note that the timestamps at the beginning of the commit history as shown on GitHub are misleading because of a history rewrite that I performed later on to remove some files that didn't really belong in the repo. GitHub appears to show the date of the rebase whereas `git log` shows the date of actual authorship (where these commits are spread over several days starting Feb 27). > I had a brief look at the encryption implementation for the token store. I mostly like the design! It’s quite smart. Thank you! I'm quite proud of this design. (Of course, the AI would never have come up with it itself, but it was pretty decent and filling in the details based on my explicit instructions.)
- max2he 1y agoInteresting to have people submit their promts to git. Do you think it'll be generally an accepted thing or was this just a showcase of how they promt?
- kentonv 1y agoI included the prompts because I personally found it extremely illuminating to see what the LLM was able to produce based on those prompts, and I figured other people would be interested to. Seems I was right. But to be clear, I had no idea how to write good prompts. I basically just wrote like I would write to a human. That seemed to work.
- mplanchard 1y agoThis is tangential to the discussion at hand, but a point I haven’t seen much in these conversations is the odd impedance mismatch between knowing you’re interacting with a tool but being asked to interact with it like a human. I personally am much less patient and forgiving of tools that I use regularly than I am of my colleagues (as I would hope is true for most of us), but it would make me uncomfortable to “treat” an LLM with the same expectations of consistency and “get out of my way” as I treat vim or emacs, even though I intellectually know it is also a non-thinking machine. I wonder about the psychological effects on myself and others long term of this kind of language-based machine interaction: will it affect our interactions with other people, or influence how we think about and what we expect from our tools? Would be curious if your experience gives you any insight into this.
- kentonv 1y agoI have actually had that thought, too. I feel bad being rude to an LLM even though it doesn't care, so I add words like "please" and sometimes even complement it on good work even though I know this is useless. Will I learn to stop doing that, and if so, will I also stop doing it to humans? I'm hoping the answer is simply "no". Plenty of people are rude in some contexts and then polite in others (especially private vs. public, or when talking to underlings vs. superiors), so it should be no problem to learn to be polite to humans even if you aren't polite to LLMs, I think? But I guess we'll see.
- user9999999999 1y agowhy on earth would you code oauth in ai at this stage?
- throwawaybob420 1y agoI’ve never seen such “walking off the cliff” behavior than from people who whole heartedly champion LLMs and the like. Leaning on and heavily relying on a black box that hallucinates gibberish to “learn”, perform your work, and review your work. All the while it literally consumes ungodly amounts of energy and is used as pretext to get rid of people. Really cool stuff! I’m sure it’s 10x’ing your life!
- ChrisArchitect 1y agoRelated: I read all of Cloudflare's Claude-generated commits https://news.ycombinator.com/item?id=44205697 https://news.ycombinator.com/item?id=44205697
- m3kw9 1y agoFor the foreseeable future software expertise is a safe job to have.
- bazhand 1y agoAs a non developer, this was incredible useful to understand the prompt structure and apply to my own Claude Code.