Oauth and enterprise auth has to be the worst thing ever made, it might be the most confusing and frustrating part of dealing with the cloud. Even the AI tools took a year to just get basic Oauth working on headless systems without assuming you could open a browser. If they're going to go down the auth rabbit hole with RBAC/IAM/Workload identities?/service accounts and all the trash the big cloud providers have, I just hope to god they leave in the simple shit for personal use. I just want a damn API key, I keep it a secret and revoke if necessary and don't need 10000 layers of auth bullshit tangled up in every layer of every platform.
What I don't understand is why OAuth is rarely talked about in a privacy context, however your OAuth provider knows all the sites you log into and when.
Why would I want the headache of securely storing credentials if I'm running a web app? I'd rather offload it onto Google. And yeah, it's probably more secure.
Why would I want the headache of having yet another login/password to remember, if (like most people) I haven't figured out password managers? I'd rather just use my Google identity, especially if I don't really care about this particular web app.
Normal people just reuse a few variations of the same password across all of their accounts. Federated identity isn't bulletproof but it beats the heck out of reusing the same password.
Do you remember when people had to "remember" a password for every service they use? It is better to use a trusted third party. Sure these third parties are big corporations, but its safer for most people to have a login that just works, even at the cost of some privacy.
People trying to remember passwords is a pretty bad security situation.
I'm not an expert but so often folks on here throw criticisms without giving credit to some of the merits of solutions. Nothing is perfect, and progress can still be made. :)
Hard to convince users that they need to be using a password manager if you run a SaaS. Also when things like LastPASS getting hacked are on the front page... imagine advising people to use that one! (I'm guilty of recommending LastPASS many years ago, before their first breach).
It probably is more secure, to be honest. I trust Google to keep my account secure more than I trust some random website to store password hashes and verify securely.
Microsoft SSO does exactly this. They let you pretend to be someone else's email, making their SSO service pointless since you still need to do email verification anyways (at which point, just send a login token to sign them in, instead of using SSO).
The only way to preserve privacy while having a central and easy authentication mechanism I can think of is to use IndieAuth[0] which is built on top of OAuth 2.0.
Of course, you will need to be your own provider, using an IndieAuth provider service defeats the purpose, which is what I see most IndieWeb devs are doing.
Totally agree. Having to handle the password reset flow requires having reliable email delivery, which can be non-trivial. I usually start with supporting Google auth, and if I need more than that I'll add Microsoft and Apple too. Everyone already has at least one of those setup.
I don't think you followed the thread. I began discussing the OAuth privacy nightmare, then the counter point was that the with email auth providers know anyway, but they don't know the login times necessarily, unlike with OAuth.
Corporations aren't interested in preserving privacy, quite the opposite. If you need OAuth for private use you'd have to roll out your own centralised directory.
For API Keys we just launched Ory Talos (https://github.com/ory/talos) - a perfect alternative for when OAuth2 is too much for the use case.
There are use cases and security concerns that legitimize using OAuth2 - with specs like DPoP you can make these flows more secure. In my view the use cases presented here is a good one for OAuth2, but it certainly doesn’t make sense everywhere - complexity makes system harder to secure.
Ory Hydra was one of the few tools I remember being actually good and lightweight and useable. Tried setting up and using KeyCloak for a while, absolute nightmare
Plus I feel like it has completely ruined typical login flows, normally a PW manager would auto fill the username + password fields, but thanks to oauth we often get only a username field, or have to click 'login with password' or some other silly step first.
OIDC can be relatively straight-forward (that is just a few JSON REST calls) if the provider isn't configured in a restrictive way. The .well-known/openid-configuration endpoint is quite helpful. Exchanging username+password (optionally with OTP) for a token is an option in the standard.
The issue is that lots of deployments are quite restrictive "for security".
OIDC is only barely more complicated than the minimum viable option for establishing someone's identity based on the word of a trusted third party.
User shows up at your login flow. You assign them a big random number identifying their user session (this is your "state")
User indicates an identity provider they'd like to use. You probably have a short list you trust.
You ask that provider for the configuration data.
You generate a big random number, that identifies this log in attempt as unique. This is your "nonce".
You send the user, along with the state and nonce, to the trusted third party. (at their "authorization endpoint")
The user proves to the trusted third party they are who they say they are. This isn't your problem.
The user comes back to you with a claimed state and a code (a big random number assigned by the trusted third party).
You check that the user's claimed state matches the state that you assigned them. This ensures that you end up authenticating the same user session as the one that started the login.
You then reach out to the third party directly (to their token endpoint), with state and code in hand, and ask them "yo, a user session with this state just claimed you sent them to me with this code. Who are they?".
And then the trusted third party sends back a token attesting "They are so and so".
The one superfluous step is that, according the spec, you're supposed to then verify the signature of that token. It is unclear to me why this is in the spec, since I just made an https request to the trusted third party. The entire security model here has assumed that trusted third party is trusted.
Don't get me wrong but data shows that you will likely fail to keep that api key a as secret and you will also fail to revoke when it becomes necessary. You will definately not going to rotate it frequently as you should.
Good thing about the OAuth2/OIDC is these things will not put the trust on the bearer of the api key, but on actual identity that needs to have the access.
My data shows that zaptheimpaler has above average likelihood to keep their secret secret.
> Good thing about the OAuth2/OIDC is these things will not put the trust on the bearer of the api key, but on actual identity that needs to have the access.
And... you do not see the myriad of problems with that? What about the OIDC provider going rogue or getting compromised? How do you ensure whatever you use to authenticate with your OIDC isn't compromised? Many identity providers and identity bearers have terrible security practices. "Add a backup email in case you lose your 2FA. Nevermind it's the same email we use for password reset."
Again, I trust zaptheimpaler to keep their secret much better than this whole pretend security theater.
And I also trust myself to keep my secrets better than this whole pretend security theater too.
I've never worked at an organization that handled their user's data/privacy/security even remotely close to how I handle my own and I wouldn't even consider myself all that paranoid. I have worked for some companies that really really should care too - there's just no incentive to really care and those in the org that try too do so will get ignored.
The data breach letters I get in the mail a few times a year back me up on this.
> I just want a damn API key, I keep it a secret and revoke if necessary and don't need 10000 layers of auth bullshit tangled up in every layer of every platform
Then implement that on your app... You are just generating a random key and storing a hash + salt.
Auth is hard only applies to auth for many users. For your own auth this is dead simple and made even simpler if you use a half decent framework...
If you are really worried about the implementation being insecure throw one of the many moderately frontier models at it, they are really not bad at finding issues in an auth system that simple.
> But all that only makes sense if you own a domain name.
I have a hard time believing the venn diagram of "has a need for an auth provider" and "has at least one domain name" isn't just a a small circle almost entirely inside a large one, and the sliver on the outside is not for any reason other than stubborn refusal.
We had a security report for a oauth vuln and it was the worst thing I have ever read, the whole thing is like spaghetti that "just works" until it doesn't because you feed it something similar.
I am tempted to agree with you because I could never quite wrap up my head around it, but I never had to implement OAuth beyond a brief skim through the doc for my own understanding. I always thought this complexity was there for some good reason (security?).
OAuth first and foremost is driven by getting secret information from, let’s say, Big Company. It’s understandable that there are many steps for some random Joe to get Google emails or Facebook DMs.
OpenID piggy-backed on it by layering on new terms to an already complex scheme. The precious, secret information from Big Company in OpenID is just Email and maybe Name and Profile Picture. Then there’s a lot of ceremony for the service using OAuth to securely get that big secret (the user’s Email, which they had to supply in the first place directly to Relying Party).
OAuth is designed so that an end-user never needs to see an API key (OAuth refresh/access token) or even know what one is. When it is implemented to the spec, that happens well.
I think that most of the "just give me an API key" comments are from a <1% of end-users (developers) that know what an API key is, and are facing a broken OAuth implementation.
Or didn't bother to read the spec to understand why it's non trivial. Things like this are complex because attacks will force it to be.
Also, the broken implementation might be an OIDC implementation that doesn't support client_credentials for example. Seen that many times and that does make it rather awkward to implement a server to server flow...
far from it! it was just designed by comitee who both future proofed it and made sure it worked on low powered devices from 1971.
i make a point to implement oauth from scratch, because using the overly complex libraries expose you to bugs such as attacker sending a token which the metadata just says "no encryption or signature. trust me bro", which is actually part of the spec if you combine some options.
while in the real world, if google or apple sends you a token that is not always the same signature cypher (one of a dozen by the spec) you are better of threating as malicious, because it pretty much is. a manual implementation of a token consumer is about 20 lines... including downloading the provider keys and checking it (which most startups never do! allowing anyone to just sign a token as anyone)
I would be so glad to see a short educational video about this. I wasn't aware of this and I think millions of other devs aren't either. Otherwise we'd never have adopted this nightmare.
I love how simple SSH is with it's PK-Auth. The only challenge is session-invalidation and key-management, but that can be surely automated, no?
Oauth is fine if you need the complexity, that is a lot of apps sharing common identity information. Then it certainly is superior to the classic workflow.
I agree that it is too complex though and app to app auth is certainly not a focus. I often still use static common secrets and see no problem with that.
I hate for apps needing to save passwords themselves, even if we have good tools today and the standard bcrypt call is reasonably safe. But then you need to reimplement password reset flows and all that ugly shit. Having that centralised is often
I would recommend self-hosting an OIDC service for that matter. The control you get also allows you to easily comply with some laws like GDPR and cousins, because you need to just purge a user in a single system.
Otherwise I thoroughly feel the frustration with IAM and the big providers. Ain't nobody got time for that and it is never a good and efficient solution.
> I would recommend self-hosting an OIDC service for that matter.
Seconded. It is fairly easy to set up, and so much easier than the cloud IAM things.
The only catch is, make sure you have some backup access to your OIDC provider in case it goes down. E.g. don’t host it on a server with SSH only accessible through VPN that is authorised using your OIDC provider, etc.
I run Codex in multiple disposable sandboxes and OAuth is such a fucking pain. I vibe-coded a project which just stores/allocates/shuffles codex auth.json files around. I have a codex instance that I manually authenticate multiple times with browser OAuth, then copy that auth.json in a store from where it's distributed to the sandboxes. And sandbox codex sometimes refreshes the authorization, so when that happens I need to send that auth.json back to the central store. Madness.
One good thing GitHub Copilot has it that you can just give it a GH_TOKEN that is valid for 6 months and stop this browser login nonsense.
Author of Ory Hydra here! Very cool to see this blog post and technical description! I never would have thought this piece of software would secure the internet companies in the world :) Also great to see that the 2.x version performs so well for you! The CPU use is ridiculously small for that scale! We have a commercial variant that‘s even faster, if you ever run into trouble.
If anyone here is interested in providing their own oauth, IAM, rebac permissions, API keys, agent security - check out our open source & commercial products at https://github.com/ory and https://www.ory.com/
Just a passerby, but wanted to say thanks for your work. Ory services are a delight and I was excited to see them spring up years ago and even more excited to see them continue to be developed and put to good use!
I used to manage a self hosted instance of the identity server framework for dotnet that ran several billions of requests per month, my experience managing OAuth and OpenID Connect at that scale was that it was pretty much a solved problem with relatively low maintenance *(it was a critical core service at our org, with heavy compliance, but our team was maybe 3 people taking care of it? it is still up and well to this day)*
I could never understand why there were so much confusion spread around this protocol, almost every junior engineer I worked with would just struggle grasping it, I cannot recommend Scott Brady's blog enough on the topic https://www.scottbrady.io/ it was illuminating to me
I think there's an essential primitive "fear" whenever authN/Z is involved that creates friction for most engineers, they're used to problem solving and this fits within a pre-condition to your problem solving so there's a cognitive tax or something around it
Wrangler, being cloudflare’s primary CLI tool, is a microcosm of exactly the problem GP was articulating: it’s focused way more on adding new commands than improving existing ones.
Many products, even supposedly “GA” ones, still lack basic operability via wrangler because instead of finishing building out its capabilities to manage existing services, they prioritized adding rudimentary support for new ones.
Nah, you don't get to claim they don't work on improving their products, and then handwave away actual updates to it with "yeah but those aren't the improvements I wanted". That's just life and priorities.
Abandoning something, and not making the changes you want to see are entirely different things.
Classic Cloudflare, for all, works well, not too expensive... but, and consequently of all those positive attributes, positioning itself at the center of everything.
My policy has been, I make sure I have an equivalent self hosted solution that I can immediately switch to, before deploying said feature to Cloudflare.
That said I only use cloudflare for piping and none of the compute stuff.
No, consolidation within the tech industry has never been good for workers or open source development. For someone who considers themselves as part of the open source community I've been extremely disappointed how anti-worker and pro-corporation you come across.
Don't worry you aren't unique in this regard, many other nonworking dev influencers say similar things: never championing for workers but somehow always championing positions that help investors + corporations first and foremost
I don't think that's necessarily true. Certainly the video streaming is expensive, but other things like workers and KV store are quite cheap and performant and powerful _if you structure your access patterns accordingly_ .
Cloudflare pricing introduces an additional dimension for when you're architecting software on top of them, but if you do it correctly, your product has the potential to be faster, cheaper, and easier to run than traditional solutions running on multiple geographically distributed VMs. You just can't approach them as if they're just another VM instance provider and expect a similar experience and pricing. What they do and price for is fundamentally different from that.
I cannot agree more. Cloudflare has some services that are really cheap (r2) to lure you into their worker "ecosystem", which is just serverless. Once you are vendor locked into their absolute garbage custom JavaScript runtime, you are pretty much forced to use their distributed database Cloudflare KV if you want good performance. Cloudflare KV is so extremely ridiculously absurdly expensive that make predatory pricing of vercel that HN likes to complain about feel like child play.
Oh no... KV is not a distributed database and is really not intended as a database alternative at all. It's more meant for distributing bits of config globally. Cost aside, writes are way too slow for database-ish use and "eventually consistent" isn't what you want for state that is changing often. Durable Objects (SQLite) or Hyperdrive (edge caching in front of a normal postgres/mysql database) are what you want, and will probably be a lot cheaper. Sorry for the confusion.
Not sure whats the play here, there is no world where this can turn out good. Cloudflare is more or less infrastructure provider, this idea of some user delegating permissions to their account to some third party client for infrastructure is ripe for abuses. If companies like AWS are not doing it then its for a good reason.
Do you understand what OAuth is? It’s like an API key but less likely to be abused. This is a good thing. It helps security in many ways and makes security flows more safe than carrying around a token.
I really feel sad about the state of security and its bit hard to unwrap in one paragraph which makes it more challenging. Let me try to be bit more verbose
Cloudflare API Keys - You create them and then use those keys directly against cloudflare API's to manage services/infrastructure in your account. How you create the keys is may be a different kind of challenge.
OAuth flow in discussion here - You are using a third party service (which registers themselves as a the client application with cloudflare), this service is going to prompt you for OAuth flow and redirect to Cloudflare, not (only) to authenticate you but it will get a access token on your behalf (your cloudflare account) from Cloudflare. Whatever this THIRD PARTY service uses this token for your behalf is going to incur infrastructure cost for your account.
Yea and if you need to use that service then an API key does the same thing. People were giving these services the API keys which isn’t great. You can argue that third party services aren’t a good idea, but then why are you using cloudflare? I don’t understand why you think this is a security issue, if you don’t trust a third party service don’t use it. You have to approve the permissions, they don’t just steal them.
Sorry if I was rude earlier but saying OAuth is some security flaw made me think that you didn’t understand what it was about; it’s just a way to grant permissions to a third party you trust. If you do then I’m curious why you think it’s flawed.
Maybe he doesn't. And I know that I don't (at least not in depth). And that's the frightening thing here. Using a protocol that many don't understand for access to valuable resources
Your go to a third party web site. They send you to your OAuth provider, like cloudflare. Cloudflare asks you to login if you’re not logged in, then asks if you want to give that party certain permissions. You say yes or no and then click approve and then you get redirected back to the third party site. They get a secure token and can use that to access the services with permissions you approved. If you don’t trust the third party then don’t approve it.
It is like an API key but you never have to touch it. The third party can encrypt it and store it securely and it never has to be copied and pasted. You can use this on backend services that need to access things too. I recently wrote an OAuth client for MCP servers for something I’m building (not gonna advertise here because that’s rude) and it’s very nice once you read the spec.
OAuth2, to be more precise, is a protocol which can be used both for authentication (verifying the user) and authorization (accessing resources on behalf of that user).
Most people in CIAM (customer identity, individuals owing their account instead of representing a company) only interact with OAuth client for authentication. They do not give access of their google account to some THIRD PARTY COMPANY.
Sure they do. All the time! For example, if you want to use a script in Google Docs these days, you have to go through an oauth flow to give that script's app permission to do certain actions in your Docs.
"Ory Enterprise License: Unlock enterprise-grade features like security SLAs for CVEs, SAML, B2B organizations, multi-tenancy, and better scalability." [0]
Or just stick with KeyCloak that offers a full self hosted product... [1]
KeyCloak is great if you want a full stack Java server to run internal workforce for example, but Ory is much better at running high scale (eg at OpenAI https://www.ory.com/case-studies/openai) and in a composable fashion.
Yes we have an commercial version because how else can one finance world class open source powering the biggest software names on the planet? It‘s a good thing that Ory has a business model that works, not a bad thing. And by the way, IBM finds ways to charge you for KeyCloak too ;)
Valid points (although Keycloak was Redhat not IBM and then donated by them to CNCF), but should "security SLAs for CVEs" be listed as a premium feature?
Looked at the case study, uses Cockroach which is now commercial, so potentially with the dual costs of Ory and Cockroach licenses, unless you need massive scale, would be too expensive for small/medium and also startups? Unless your sole focus is on enterprises?
My mistake - I thought it‘s now just under the IBM corp but it is indeed in CNCF. Still, IBM offers a commercial product around KeyCloak.
If you serve 900m weekly active users, you need this type of distributed database architecture that is expensive to run. But at that point the cost of running it is a fraction of overall infra spend. No start up really needs this level of scale, only Enterprises (hence it‘s gated). Making Cockroach work is more work than just wiring up the SQL, you actually need to deal with it like dynamodb under the hood and use primary keys efficiently, avoid hotspots, and all that jazz.
Most companies (like Cloudflare!) do just fine with Postgres and one of our services. Ory Hydra is written in Go, doesn’t need JVM, very little RAM, doesn’t need caches or start up time due to cold starts. The architecture is different and that makes it cheap and fast to run. From the blog post - they run Hydra on 0.6 vCPU and 200MB of RAM. That’s probably as cheap as it gets!
It‘s a different tool for a different problem than KeyCloak - both have their place.
Having dealt with Keycloak in production it's not that great. Maybe if it didn't use Infinispan and JGroups internally. Both are absurdly complex for no reason.
>Earlier this month, we announced self-managed OAuth, making it easier for customers to create and manage their own OAuth clients for delegated access to the Cloudflare API.
They're letting you host an OAuth system to approve/deny access to your own resources, so you can build whatever logic you like, rather than waiting on them to allow you to do X under Y conditions. Essentially "log into CloudFlare" -> CF sees you're using this self-managed OAuth -> redirect to your OAuth -> CF trusts your response, and approves access to your account if you approve access.
OAuth is great when you actually need user delegation. For simple server-to-server API access, scoped keys with rotation, audit logs, and fast revocation are often a much better developer experience.
You'd think implementing OAuth2 were splitting the atom the way so many dev teams won't even consider rolling their own or using the multiple well-tested free libraries.
I wish Cloudflare provided a paved path for user auth.
Better Auth seems to be the most common recommendation for Typescript applications, but there currently doesn't seem to be an official integration with Workers either from Better Auth or from Cloudflare.
I currently use Supabase to avoid having to set up my own user auth on Workers, but I would much prefer to use D1 etc.
As much as I’d like to love Better Auth, the assumptions they make sometimes are so damn annoying. Having to resort to hacks to e.g. support an OIDC provider that doesn’t return user’s email (like Telegram) is a PITA.
I find Lucia Auth’s approach more useful in the long run – you have some boilerplate living on your codebase but you own it completely and it doesn’t try to make decisions for you: https://lucia-auth.com/
---
That said, why don’t you use Better Auth with Drizzle and the D1 adapter?
What’s ironic about this is they technically already shipped a looser version. The entire cf api is exposed as an MCP server which supports OAuth and dynamic client registration.
Not sure why they don’t just support DCR or CIMD for this too
Cloudflare turning into a Cloud platform is undoing what it was really doing well: making small clouds and diy hosting manageable in the hostile web environment.
Once their revenue from Cloud services overtakes their core offering, bye bye Cloudflare free and so on.
If you carefully read the article, it just explain how it is an economic decision, and one which sooner or later will be no longer the case once they can capitalise on with anything above free, which is the lowest of the lowest bars.
But even to entertain this is crazy, not because of decades of history of capitalist and market enterprise in general, but very specific cases of Technology Companies starting with these kind of feel good ideas and declaring "Don't be evil" or things like " access, safety, and shared prosperity" as their core ideals, turn into absolute panopticon and collaborate with unjust killing of women and children in less than a decade.
My pet peeve is the standard OpenID connect implementation of OAuth for SPAs - which will probably use the PKCE code flow. It is probably for historic reasons and old browser compat, but exposing access token and revocation token to javascript is IMHO just madness. In modern security flows you would save those tokens into cookies that are HttpOnly and SameSite=strict and prevent a myriad of JS based attack vectors.
It's full of technical details, but I'm really not sure who they're for. There's nothing particularly novel or impressive. If anything the fact that it took them this long should be embarrassing. They pad it out with a table of stats that are just kind of meh? Congrats I guess for releasing something without burning the house down?
As an on-and-off customer of theirs I tried to quickly skim for some of the details that would impact me, the theoretical end-user, but the vast majority of TFA is just about how they pulled off this apparent feat of engineering.
I'm not trying to be pessimistic, and I don't fault the author (but I question the culture). I honestly don't get who this is for.
For the record this is something they should have had... at least six or seven years ago?
I for one appreciate them sharing this and found it a very interesting read. Many of us don't have experiences at companies at this scale and so it's nice whenever I get to read about what happens behind the scene.
Usually I expect an eng blog post to be a recruitment vehicle, wherein the authors articulate a really hard problem they solved, or some novel approach they took, or the cool new open source project they released (for their future SaaS play).
But this is so mundane it bothers me in a way I find surprising. It's more about how they made some questionable choices in the past and how they finally paid off that technical debt. Is it interesting? Perhaps I am just getting old and jaded.
What I find odd is how light TFA is on actual details as to what it is they shipped.
This is the kind of thing I'd ship internally to the org as part of a weekly update or something, but not what I'd expect on a public-facing corporate blog.
I hope Cloudflare does not turn into Google, with so many different things that they will eventually kill all of these services randomly because of the maintenance cost.
Oauth and enterprise auth has to be the worst thing ever made, it might be the most confusing and frustrating part of dealing with the cloud. Even the AI tools took a year to just get basic Oauth working on headless systems without assuming you could open a browser. If they're going to go down the auth rabbit hole with RBAC/IAM/Workload identities?/service accounts and all the trash the big cloud providers have, I just hope to god they leave in the simple shit for personal use. I just want a damn API key, I keep it a secret and revoke if necessary and don't need 10000 layers of auth bullshit tangled up in every layer of every platform.
What I don't understand is why OAuth is rarely talked about in a privacy context, however your OAuth provider knows all the sites you log into and when.
It's a privacy nightmare.
For enterprise, the ability to shut out a user with one click is the overriding security feature.
I don’t know why anyone wants to use a federated identity to sign into things. Where did the messaging that it’s more secure come from, Google?
Why would I want the headache of securely storing credentials if I'm running a web app? I'd rather offload it onto Google. And yeah, it's probably more secure.
Why would I want the headache of having yet another login/password to remember, if (like most people) I haven't figured out password managers? I'd rather just use my Google identity, especially if I don't really care about this particular web app.
This is only true if one doesn’t care about spam going to that identity
Normal people just reuse a few variations of the same password across all of their accounts. Federated identity isn't bulletproof but it beats the heck out of reusing the same password.
Login tokens solves the re-use (but does put the onus on their email being secure).
Do you remember when people had to "remember" a password for every service they use? It is better to use a trusted third party. Sure these third parties are big corporations, but its safer for most people to have a login that just works, even at the cost of some privacy.
People trying to remember passwords is a pretty bad security situation.
I'm not an expert but so often folks on here throw criticisms without giving credit to some of the merits of solutions. Nothing is perfect, and progress can still be made. :)
A password manager can both take care of remembering unique passwords and allow privacy options
Hard to convince users that they need to be using a password manager if you run a SaaS. Also when things like LastPASS getting hacked are on the front page... imagine advising people to use that one! (I'm guilty of recommending LastPASS many years ago, before their first breach).
Good luck getting people to use one! Even when they do, the UX is a nightmare.
> its safer for most people to have a login that just works, even at the cost of some privacy.
Respectfully, I disagree in a time when all your data is being slurped up and resold constantly I hate any additional costs to my privacy.
> People trying to remember passwords is a pretty bad security situation.
But that's their problem, not mine. I'm an adult and I use a password manager.
It probably is more secure, to be honest. I trust Google to keep my account secure more than I trust some random website to store password hashes and verify securely.
Your OAuth provider can also vouch for anyone who pretends to be you, if they so desire. They can give access to anyone, including themselves.
Microsoft SSO does exactly this. They let you pretend to be someone else's email, making their SSO service pointless since you still need to do email verification anyways (at which point, just send a login token to sign them in, instead of using SSO).
Slight tangent.
The only way to preserve privacy while having a central and easy authentication mechanism I can think of is to use IndieAuth[0] which is built on top of OAuth 2.0.
Of course, you will need to be your own provider, using an IndieAuth provider service defeats the purpose, which is what I see most IndieWeb devs are doing.
You will need to own a (sub)domain though.
[0] https://indieweb.org/IndieAuth?redirected=IndieAuth
WebFinger + self-hosted Oauth provider is indeed nice. Unfortunately not widely available.
Take a look at Google's FedCM protocol as well
"It's a privacy nightmare."
Privacy nightmare in the real world, "tech" company wet dream in SillyCon Valley
There's two sides to every coin
I've done a bit of experimentation in this area. Check out https://lastlogin.net/.
You may also be interested in the FedCM protocol Google is working on.
It also makes authentication Not Your Problem. Getting someone else to handle password resets alone seems worth the squeeze.
Totally agree. Having to handle the password reset flow requires having reliable email delivery, which can be non-trivial. I usually start with supporting Google auth, and if I need more than that I'll add Microsoft and Apple too. Everyone already has at least one of those setup.
Though given most people use gmail or outlook, the two main oauth providers (Google and Microsoft) will know anyway
True they'd know which sites you've signed up to, but not the login times, unless the service emails you every time you log in.
Every time you sign into an app, you get redirected to the auth provider to open a session there. So of course they know your login times.
I don't think you followed the thread. I began discussing the OAuth privacy nightmare, then the counter point was that the with email auth providers know anyway, but they don't know the login times necessarily, unlike with OAuth.
Three main providers
(Apple login is in nearly every iOS app and most websites)
Corporations aren't interested in preserving privacy, quite the opposite. If you need OAuth for private use you'd have to roll out your own centralised directory.
I wouldn't call it a nightmare. It's a well documented design choice
Centralised identity is basically the government... and having some other entity behave the same way is not good.
there are some emerging mechanisms for offline verification that don't require AS in the OAuth WG. (I'm working on one of them)
OAuth2 is complex and often not the right tool. I wrote Ory Hydra and also a blog post when OAuth2 is/is not a good idea: https://www.ory.com/blog/oauth2-openid-connect-do-you-need-u...
For API Keys we just launched Ory Talos (https://github.com/ory/talos) - a perfect alternative for when OAuth2 is too much for the use case.
There are use cases and security concerns that legitimize using OAuth2 - with specs like DPoP you can make these flows more secure. In my view the use cases presented here is a good one for OAuth2, but it certainly doesn’t make sense everywhere - complexity makes system harder to secure.
Ory Hydra was one of the few tools I remember being actually good and lightweight and useable. Tried setting up and using KeyCloak for a while, absolute nightmare
Plus I feel like it has completely ruined typical login flows, normally a PW manager would auto fill the username + password fields, but thanks to oauth we often get only a username field, or have to click 'login with password' or some other silly step first.
OIDC can be relatively straight-forward (that is just a few JSON REST calls) if the provider isn't configured in a restrictive way. The .well-known/openid-configuration endpoint is quite helpful. Exchanging username+password (optionally with OTP) for a token is an option in the standard. The issue is that lots of deployments are quite restrictive "for security".
OIDC is only barely more complicated than the minimum viable option for establishing someone's identity based on the word of a trusted third party.
User shows up at your login flow. You assign them a big random number identifying their user session (this is your "state")
User indicates an identity provider they'd like to use. You probably have a short list you trust.
You ask that provider for the configuration data.
You generate a big random number, that identifies this log in attempt as unique. This is your "nonce".
You send the user, along with the state and nonce, to the trusted third party. (at their "authorization endpoint")
The user proves to the trusted third party they are who they say they are. This isn't your problem.
The user comes back to you with a claimed state and a code (a big random number assigned by the trusted third party).
You check that the user's claimed state matches the state that you assigned them. This ensures that you end up authenticating the same user session as the one that started the login.
You then reach out to the third party directly (to their token endpoint), with state and code in hand, and ask them "yo, a user session with this state just claimed you sent them to me with this code. Who are they?".
And then the trusted third party sends back a token attesting "They are so and so".
The one superfluous step is that, according the spec, you're supposed to then verify the signature of that token. It is unclear to me why this is in the spec, since I just made an https request to the trusted third party. The entire security model here has assumed that trusted third party is trusted.
Don't get me wrong but data shows that you will likely fail to keep that api key a as secret and you will also fail to revoke when it becomes necessary. You will definately not going to rotate it frequently as you should.
Good thing about the OAuth2/OIDC is these things will not put the trust on the bearer of the api key, but on actual identity that needs to have the access.
My data shows that zaptheimpaler has above average likelihood to keep their secret secret.
> Good thing about the OAuth2/OIDC is these things will not put the trust on the bearer of the api key, but on actual identity that needs to have the access.
And... you do not see the myriad of problems with that? What about the OIDC provider going rogue or getting compromised? How do you ensure whatever you use to authenticate with your OIDC isn't compromised? Many identity providers and identity bearers have terrible security practices. "Add a backup email in case you lose your 2FA. Nevermind it's the same email we use for password reset."
Again, I trust zaptheimpaler to keep their secret much better than this whole pretend security theater.
And I also trust myself to keep my secrets better than this whole pretend security theater too.
I've never worked at an organization that handled their user's data/privacy/security even remotely close to how I handle my own and I wouldn't even consider myself all that paranoid. I have worked for some companies that really really should care too - there's just no incentive to really care and those in the org that try too do so will get ignored.
The data breach letters I get in the mail a few times a year back me up on this.
Can you share source of this data? I have my doubts about the quality of the data, since OAuth2 is such a complex system with so many footguns.
In the end there is always some long lived secret. What changes is just where and how it is stored, secured and used.
I bet we can generalize to say that data shows that you will likely fail to properly secure any secret (including the ones used in OAuth2).
EDIT: An example: https://news.ycombinator.com/item?id=37973937
> but on actual identity that needs to have the access.
Not quite. You shift the trust from the key bearer (the most interested party in all of this) to the identity provider.
> I just want a damn API key, I keep it a secret and revoke if necessary and don't need 10000 layers of auth bullshit tangled up in every layer of every platform
Then implement that on your app... You are just generating a random key and storing a hash + salt.
Auth is hard only applies to auth for many users. For your own auth this is dead simple and made even simpler if you use a half decent framework...
If you are really worried about the implementation being insecure throw one of the many moderately frontier models at it, they are really not bad at finding issues in an auth system that simple.
It's the worst delegated authorisation system except for all the others that have been tried from time to time.
The original OpenID was fine.
IndieAuth is fine (but I’ve yet to see an implementation out in the wild).
Tailscale’s implementation of OIDC is nice: https://tailscale.com/docs/integrations/identity/custom-oidc
But all that only makes sense if you own a domain name.
> But all that only makes sense if you own a domain name.
I have a hard time believing the venn diagram of "has a need for an auth provider" and "has at least one domain name" isn't just a a small circle almost entirely inside a large one, and the sliver on the outside is not for any reason other than stubborn refusal.
OAuth 2.0 is a hate crime against security given its complexity.
When I really dove into it, I understood mostly why all the complexity was all there if I cared about data at the identity provider.
When it’s only used for SSO, it’s extreme overkill.
We had a security report for a oauth vuln and it was the worst thing I have ever read, the whole thing is like spaghetti that "just works" until it doesn't because you feed it something similar.
Never want to touch oauth, it's a fucked spec.
I am tempted to agree with you because I could never quite wrap up my head around it, but I never had to implement OAuth beyond a brief skim through the doc for my own understanding. I always thought this complexity was there for some good reason (security?).
OAuth first and foremost is driven by getting secret information from, let’s say, Big Company. It’s understandable that there are many steps for some random Joe to get Google emails or Facebook DMs.
OpenID piggy-backed on it by layering on new terms to an already complex scheme. The precious, secret information from Big Company in OpenID is just Email and maybe Name and Profile Picture. Then there’s a lot of ceremony for the service using OAuth to securely get that big secret (the user’s Email, which they had to supply in the first place directly to Relying Party).
OAuth is designed so that an end-user never needs to see an API key (OAuth refresh/access token) or even know what one is. When it is implemented to the spec, that happens well.
I think that most of the "just give me an API key" comments are from a <1% of end-users (developers) that know what an API key is, and are facing a broken OAuth implementation.
> and are facing a broken OAuth implementation.
Or didn't bother to read the spec to understand why it's non trivial. Things like this are complex because attacks will force it to be.
Also, the broken implementation might be an OIDC implementation that doesn't support client_credentials for example. Seen that many times and that does make it rather awkward to implement a server to server flow...
> was there for some good reason (security?).
To cover the myriad of (sometimes downright stupid) requirements that large enterprises have.
> I always thought this complexity was there for some good reason (security?).
It's just design by committee.
far from it! it was just designed by comitee who both future proofed it and made sure it worked on low powered devices from 1971.
i make a point to implement oauth from scratch, because using the overly complex libraries expose you to bugs such as attacker sending a token which the metadata just says "no encryption or signature. trust me bro", which is actually part of the spec if you combine some options.
while in the real world, if google or apple sends you a token that is not always the same signature cypher (one of a dozen by the spec) you are better of threating as malicious, because it pretty much is. a manual implementation of a token consumer is about 20 lines... including downloading the provider keys and checking it (which most startups never do! allowing anyone to just sign a token as anyone)
I would be so glad to see a short educational video about this. I wasn't aware of this and I think millions of other devs aren't either. Otherwise we'd never have adopted this nightmare.
I love how simple SSH is with it's PK-Auth. The only challenge is session-invalidation and key-management, but that can be surely automated, no?
Oauth is fine if you need the complexity, that is a lot of apps sharing common identity information. Then it certainly is superior to the classic workflow.
I agree that it is too complex though and app to app auth is certainly not a focus. I often still use static common secrets and see no problem with that.
I hate for apps needing to save passwords themselves, even if we have good tools today and the standard bcrypt call is reasonably safe. But then you need to reimplement password reset flows and all that ugly shit. Having that centralised is often
I would recommend self-hosting an OIDC service for that matter. The control you get also allows you to easily comply with some laws like GDPR and cousins, because you need to just purge a user in a single system.
Otherwise I thoroughly feel the frustration with IAM and the big providers. Ain't nobody got time for that and it is never a good and efficient solution.
> I would recommend self-hosting an OIDC service for that matter.
Seconded. It is fairly easy to set up, and so much easier than the cloud IAM things.
The only catch is, make sure you have some backup access to your OIDC provider in case it goes down. E.g. don’t host it on a server with SSH only accessible through VPN that is authorised using your OIDC provider, etc.
> I keep it a secret and revoke if necessary and don't need 10000 layers of auth bullshit tangled up in every layer of every platform.
Expect it. Security is hard and the companies with deep pockets are happy to pay the bill that meets their cybersecurity insurance requirements.
I run Codex in multiple disposable sandboxes and OAuth is such a fucking pain. I vibe-coded a project which just stores/allocates/shuffles codex auth.json files around. I have a codex instance that I manually authenticate multiple times with browser OAuth, then copy that auth.json in a store from where it's distributed to the sandboxes. And sandbox codex sometimes refreshes the authorization, so when that happens I need to send that auth.json back to the central store. Madness.
One good thing GitHub Copilot has it that you can just give it a GH_TOKEN that is valid for 6 months and stop this browser login nonsense.
What does codex's auth.json file have to do with OAuth?
Author of Ory Hydra here! Very cool to see this blog post and technical description! I never would have thought this piece of software would secure the internet companies in the world :) Also great to see that the 2.x version performs so well for you! The CPU use is ridiculously small for that scale! We have a commercial variant that‘s even faster, if you ever run into trouble.
If anyone here is interested in providing their own oauth, IAM, rebac permissions, API keys, agent security - check out our open source & commercial products at https://github.com/ory and https://www.ory.com/
Just a passerby, but wanted to say thanks for your work. Ory services are a delight and I was excited to see them spring up years ago and even more excited to see them continue to be developed and put to good use!
Truly appreciated, thank you :)
thank u for Hydra, its great!
I used to manage a self hosted instance of the identity server framework for dotnet that ran several billions of requests per month, my experience managing OAuth and OpenID Connect at that scale was that it was pretty much a solved problem with relatively low maintenance *(it was a critical core service at our org, with heavy compliance, but our team was maybe 3 people taking care of it? it is still up and well to this day)*
I could never understand why there were so much confusion spread around this protocol, almost every junior engineer I worked with would just struggle grasping it, I cannot recommend Scott Brady's blog enough on the topic https://www.scottbrady.io/ it was illuminating to me
I think there's an essential primitive "fear" whenever authN/Z is involved that creates friction for most engineers, they're used to problem solving and this fits within a pre-condition to your problem solving so there's a cognitive tax or something around it
Cloudflare really likes to publish new projects, but improving them in the future is not really their style. Some examples:
- They launched Cloudflare Web Analytics in 2020, but it still does not support basic things such as UTM parameters or custom events
- With wrangler (their CLI), you still cannot undeploy a Cloudflare Page
The last commit to wrangler was 2 hours ago?
https://github.com/cloudflare/workers-sdk/tree/main/packages...
That’s exactly the point.
Wrangler, being cloudflare’s primary CLI tool, is a microcosm of exactly the problem GP was articulating: it’s focused way more on adding new commands than improving existing ones.
Many products, even supposedly “GA” ones, still lack basic operability via wrangler because instead of finishing building out its capabilities to manage existing services, they prioritized adding rudimentary support for new ones.
Nah, you don't get to claim they don't work on improving their products, and then handwave away actual updates to it with "yeah but those aren't the improvements I wanted". That's just life and priorities.
Abandoning something, and not making the changes you want to see are entirely different things.
Sure he does.
It's not handwaving to complain that shipped features are never completed and a functional CLI for fundamental and critical tasks is never delivered.
I suspect CF is their future CLI.
Classic Cloudflare, for all, works well, not too expensive... but, and consequently of all those positive attributes, positioning itself at the center of everything.
i mean. fair trade?
It's a good move for them but it's problematic for anybody who cares about a decentralized Internet.
My policy has been, I make sure I have an equivalent self hosted solution that I can immediately switch to, before deploying said feature to Cloudflare.
That said I only use cloudflare for piping and none of the compute stuff.
Indeed, a self-hosted compatible fallback is a great failsafe.
No, consolidation within the tech industry has never been good for workers or open source development. For someone who considers themselves as part of the open source community I've been extremely disappointed how anti-worker and pro-corporation you come across.
Don't worry you aren't unique in this regard, many other nonworking dev influencers say similar things: never championing for workers but somehow always championing positions that help investors + corporations first and foremost
Cloudflare is one of the most expensive providers out there once you step out of the basics. Look at their video streaming.
I don't think that's necessarily true. Certainly the video streaming is expensive, but other things like workers and KV store are quite cheap and performant and powerful _if you structure your access patterns accordingly_ .
Cloudflare pricing introduces an additional dimension for when you're architecting software on top of them, but if you do it correctly, your product has the potential to be faster, cheaper, and easier to run than traditional solutions running on multiple geographically distributed VMs. You just can't approach them as if they're just another VM instance provider and expect a similar experience and pricing. What they do and price for is fundamentally different from that.
Maybe it depends on product offering. WAF + CDN was competitive with Akamai (through a VAR) and AWS and came with free Zero Trust seats.
Iirc Argo and some other routing products are quite expensive.
I cannot agree more. Cloudflare has some services that are really cheap (r2) to lure you into their worker "ecosystem", which is just serverless. Once you are vendor locked into their absolute garbage custom JavaScript runtime, you are pretty much forced to use their distributed database Cloudflare KV if you want good performance. Cloudflare KV is so extremely ridiculously absurdly expensive that make predatory pricing of vercel that HN likes to complain about feel like child play.
Oh no... KV is not a distributed database and is really not intended as a database alternative at all. It's more meant for distributing bits of config globally. Cost aside, writes are way too slow for database-ish use and "eventually consistent" isn't what you want for state that is changing often. Durable Objects (SQLite) or Hyperdrive (edge caching in front of a normal postgres/mysql database) are what you want, and will probably be a lot cheaper. Sorry for the confusion.
Not sure whats the play here, there is no world where this can turn out good. Cloudflare is more or less infrastructure provider, this idea of some user delegating permissions to their account to some third party client for infrastructure is ripe for abuses. If companies like AWS are not doing it then its for a good reason.
AWS do exactly this. An example use-case is IAM can grant permission to update a Lambda to a Github action running in a given repository.
Personally I dont like the way they do it, its hard to understand, if anything its convoluted.
In case of AWS, you add Github as an IDP (OIDC provider) and associate a role to it.
Github is now authenticating into AWS, scoped to the github repository where its configured and the AWS role it can assume
Its not really a typical OAuth2 or OIDC flow. And yes its better than storing the keys.
Github is not the OAuth client here.
Do you understand what OAuth is? It’s like an API key but less likely to be abused. This is a good thing. It helps security in many ways and makes security flows more safe than carrying around a token.
I really feel sad about the state of security and its bit hard to unwrap in one paragraph which makes it more challenging. Let me try to be bit more verbose
Cloudflare API Keys - You create them and then use those keys directly against cloudflare API's to manage services/infrastructure in your account. How you create the keys is may be a different kind of challenge.
OAuth flow in discussion here - You are using a third party service (which registers themselves as a the client application with cloudflare), this service is going to prompt you for OAuth flow and redirect to Cloudflare, not (only) to authenticate you but it will get a access token on your behalf (your cloudflare account) from Cloudflare. Whatever this THIRD PARTY service uses this token for your behalf is going to incur infrastructure cost for your account.
Yea and if you need to use that service then an API key does the same thing. People were giving these services the API keys which isn’t great. You can argue that third party services aren’t a good idea, but then why are you using cloudflare? I don’t understand why you think this is a security issue, if you don’t trust a third party service don’t use it. You have to approve the permissions, they don’t just steal them.
Sorry if I was rude earlier but saying OAuth is some security flaw made me think that you didn’t understand what it was about; it’s just a way to grant permissions to a third party you trust. If you do then I’m curious why you think it’s flawed.
Maybe he doesn't. And I know that I don't (at least not in depth). And that's the frightening thing here. Using a protocol that many don't understand for access to valuable resources
OAuth is pretty simple, just read the spec.
Your go to a third party web site. They send you to your OAuth provider, like cloudflare. Cloudflare asks you to login if you’re not logged in, then asks if you want to give that party certain permissions. You say yes or no and then click approve and then you get redirected back to the third party site. They get a secure token and can use that to access the services with permissions you approved. If you don’t trust the third party then don’t approve it.
It is like an API key but you never have to touch it. The third party can encrypt it and store it securely and it never has to be copied and pasted. You can use this on backend services that need to access things too. I recently wrote an OAuth client for MCP servers for something I’m building (not gonna advertise here because that’s rude) and it’s very nice once you read the spec.
You're right. Crazy how we ended with so many different implementations.
How different is this to, eg, the Google developer program, in which I can create a new OAuth client for Google users?
OAuth2, to be more precise, is a protocol which can be used both for authentication (verifying the user) and authorization (accessing resources on behalf of that user).
Most people in CIAM (customer identity, individuals owing their account instead of representing a company) only interact with OAuth client for authentication. They do not give access of their google account to some THIRD PARTY COMPANY.
Sure they do. All the time! For example, if you want to use a script in Google Docs these days, you have to go through an oauth flow to give that script's app permission to do certain actions in your Docs.
"Ory Enterprise License: Unlock enterprise-grade features like security SLAs for CVEs, SAML, B2B organizations, multi-tenancy, and better scalability." [0]
Or just stick with KeyCloak that offers a full self hosted product... [1]
[0]https://github.com/ory [1]https://www.keycloak.org/
KeyCloak is great if you want a full stack Java server to run internal workforce for example, but Ory is much better at running high scale (eg at OpenAI https://www.ory.com/case-studies/openai) and in a composable fashion.
Yes we have an commercial version because how else can one finance world class open source powering the biggest software names on the planet? It‘s a good thing that Ory has a business model that works, not a bad thing. And by the way, IBM finds ways to charge you for KeyCloak too ;)
Valid points (although Keycloak was Redhat not IBM and then donated by them to CNCF), but should "security SLAs for CVEs" be listed as a premium feature?
Looked at the case study, uses Cockroach which is now commercial, so potentially with the dual costs of Ory and Cockroach licenses, unless you need massive scale, would be too expensive for small/medium and also startups? Unless your sole focus is on enterprises?
And Keycloak also has such a implementation https://www.cockroachlabs.com/blog/deploying-keycloak-on-coc...
My mistake - I thought it‘s now just under the IBM corp but it is indeed in CNCF. Still, IBM offers a commercial product around KeyCloak.
If you serve 900m weekly active users, you need this type of distributed database architecture that is expensive to run. But at that point the cost of running it is a fraction of overall infra spend. No start up really needs this level of scale, only Enterprises (hence it‘s gated). Making Cockroach work is more work than just wiring up the SQL, you actually need to deal with it like dynamodb under the hood and use primary keys efficiently, avoid hotspots, and all that jazz.
Most companies (like Cloudflare!) do just fine with Postgres and one of our services. Ory Hydra is written in Go, doesn’t need JVM, very little RAM, doesn’t need caches or start up time due to cold starts. The architecture is different and that makes it cheap and fast to run. From the blog post - they run Hydra on 0.6 vCPU and 200MB of RAM. That’s probably as cheap as it gets!
It‘s a different tool for a different problem than KeyCloak - both have their place.
Just for clarity: Cloudflare runs authentik for their workforce identity. (source/disclosure: am CEO)
Glad to see them making use of Hydra for OAuth apps!
Yes, Java based is never going to be as good as a more modern language like Go
Having dealt with Keycloak in production it's not that great. Maybe if it didn't use Infinispan and JGroups internally. Both are absurdly complex for no reason.
Keycloak.
This is basically about OAuth for accessing a Cloudflare account, not a CF-hosted generic 'Login' type stuff for custom apps
Good thing they're laying off more of their workforce to support these new products https://app.dealroom.co/news/feed/cloudflare-ceo-warns-ai-dr...
I thought I understood what Oauth was (a standardized protocol to provide per-client access keys), but this article confuses me.
What's a "self-managed" Oauth here? What is access is being granted to, who are the clients, who are the partners...?
Anyone care to elaborate?
>Earlier this month, we announced self-managed OAuth, making it easier for customers to create and manage their own OAuth clients for delegated access to the Cloudflare API.
They're letting you host an OAuth system to approve/deny access to your own resources, so you can build whatever logic you like, rather than waiting on them to allow you to do X under Y conditions. Essentially "log into CloudFlare" -> CF sees you're using this self-managed OAuth -> redirect to your OAuth -> CF trusts your response, and approves access to your account if you approve access.
Means you can basically host your own AS
OAuth is great when you actually need user delegation. For simple server-to-server API access, scoped keys with rotation, audit logs, and fast revocation are often a much better developer experience.
You'd think implementing OAuth2 were splitting the atom the way so many dev teams won't even consider rolling their own or using the multiple well-tested free libraries.
I wish Cloudflare provided a paved path for user auth.
Better Auth seems to be the most common recommendation for Typescript applications, but there currently doesn't seem to be an official integration with Workers either from Better Auth or from Cloudflare.
I currently use Supabase to avoid having to set up my own user auth on Workers, but I would much prefer to use D1 etc.
As much as I’d like to love Better Auth, the assumptions they make sometimes are so damn annoying. Having to resort to hacks to e.g. support an OIDC provider that doesn’t return user’s email (like Telegram) is a PITA.
I find Lucia Auth’s approach more useful in the long run – you have some boilerplate living on your codebase but you own it completely and it doesn’t try to make decisions for you: https://lucia-auth.com/
---
That said, why don’t you use Better Auth with Drizzle and the D1 adapter?
I’ve done it in one of my projects here using Drizzle, and it’s worked fine in testing so far.
https://github.com/rorz/manual.email/blob/main/packages/db/s...
What’s ironic about this is they technically already shipped a looser version. The entire cf api is exposed as an MCP server which supports OAuth and dynamic client registration.
Not sure why they don’t just support DCR or CIMD for this too
Can't wait to have half the internet's auth sessions die because of an outage
Cloudflare turning into a Cloud platform is undoing what it was really doing well: making small clouds and diy hosting manageable in the hostile web environment.
Once their revenue from Cloud services overtakes their core offering, bye bye Cloudflare free and so on.
Cloudflare free is the business model: https://blog.cloudflare.com/cloudflares-commitment-to-free/
If you carefully read the article, it just explain how it is an economic decision, and one which sooner or later will be no longer the case once they can capitalise on with anything above free, which is the lowest of the lowest bars.
But even to entertain this is crazy, not because of decades of history of capitalist and market enterprise in general, but very specific cases of Technology Companies starting with these kind of feel good ideas and declaring "Don't be evil" or things like " access, safety, and shared prosperity" as their core ideals, turn into absolute panopticon and collaborate with unjust killing of women and children in less than a decade.
The market isn't for free.
I doubt it. It’s cheap to run and a good funnel
> Once their revenue from Cloud services overtakes their core offering, bye bye Cloudflare free and so on.
Wait so what do you think their core offering is?
Man-in-the-middle everything.
DDoS Protection?
By proxying through their Cloud?
You don't know Cloudflare?
Their first products were production grade examples of the SDN that required a lot of bandwidth (DDOS/CDN).
The cloud is a logical continuation.
Their business was always the "internet", see their ticker => NET.
Dev free is part of the marketing cost and would stay under the current leadership.
Title: Unlocking the Cloudflare app ecosystem with OAuth for all
Nice, but as usual if you want a 3-step “getting started” example you have to wade through the docs, and even then…
I have shifted all my apps backend as much as possible to cloudflare. Get my domains from it, all security stuff. hosting, etc
Love em., greatest tech company of all time. One stop shop.
Cloudflare to cut about 20% of its workforce
https://news.ycombinator.com/item?id=48054423
My pet peeve is the standard OpenID connect implementation of OAuth for SPAs - which will probably use the PKCE code flow. It is probably for historic reasons and old browser compat, but exposing access token and revocation token to javascript is IMHO just madness. In modern security flows you would save those tokens into cookies that are HttpOnly and SameSite=strict and prevent a myriad of JS based attack vectors.
This is such a weird blog post.
It's full of technical details, but I'm really not sure who they're for. There's nothing particularly novel or impressive. If anything the fact that it took them this long should be embarrassing. They pad it out with a table of stats that are just kind of meh? Congrats I guess for releasing something without burning the house down?
As an on-and-off customer of theirs I tried to quickly skim for some of the details that would impact me, the theoretical end-user, but the vast majority of TFA is just about how they pulled off this apparent feat of engineering.
I'm not trying to be pessimistic, and I don't fault the author (but I question the culture). I honestly don't get who this is for.
For the record this is something they should have had... at least six or seven years ago?
I for one appreciate them sharing this and found it a very interesting read. Many of us don't have experiences at companies at this scale and so it's nice whenever I get to read about what happens behind the scene.
Usually I expect an eng blog post to be a recruitment vehicle, wherein the authors articulate a really hard problem they solved, or some novel approach they took, or the cool new open source project they released (for their future SaaS play).
But this is so mundane it bothers me in a way I find surprising. It's more about how they made some questionable choices in the past and how they finally paid off that technical debt. Is it interesting? Perhaps I am just getting old and jaded.
What I find odd is how light TFA is on actual details as to what it is they shipped.
This is the kind of thing I'd ship internally to the org as part of a weekly update or something, but not what I'd expect on a public-facing corporate blog.
the end game: they will start requiring proof of id to access resources they host.
probably getting ahead of something the UK and some us states will require soon, as they already require from the sites behind cloudflare.
I hope Cloudflare does not turn into Google, with so many different things that they will eventually kill all of these services randomly because of the maintenance cost.
I still kind of think of Cloudflare as "big ass CDN".
I can't keep track of all the new things they do. Something-something-R2? Maybe?