It's a privacy nightmare.
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 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.
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. :)
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.
(Apple login is in nearly every iOS app and most websites)
Privacy nightmare in the real world, "tech" company wet dream in SillyCon Valley
You may also be interested in the FedCM protocol Google is working on.
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.
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.
> 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.
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.
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
Not quite. You shift the trust from the key bearer (the most interested party in all of this) to the identity provider.
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.
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.
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.
Never want to touch oauth, it's a fucked spec.
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...
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).
To cover the myriad of (sometimes downright stupid) requirements that large enterprises have.
It's just design by committee.
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)
When it’s only used for SSO, it’s extreme overkill.
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?
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.
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.
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.
Expect it. Security is hard and the companies with deep pockets are happy to pay the bill that meets their cybersecurity insurance requirements.
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.
Iirc Argo and some other routing products are quite expensive.
That said I only use cloudflare for piping and none of the compute stuff.
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
Having your workers in-house whole other businesses/industries is also not good for workers, because the problem space of that grants their actual employment won't get the required attention.
Or just stick with KeyCloak that offers a full self hosted product... [1]
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 ;)
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...
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.
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/
- 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
https://github.com/cloudflare/workers-sdk/tree/main/packages...
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.
Abandoning something, and not making the changes you want to see are entirely different things.
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
Anyway good start in the right direction from Cloudflare, yet still long way to go especially compare to the full Ory's offering its built on. Ory's Kratos handles identity, login, registration, recovery, MFA... https://github.com/ory
IMHO full scope should include plans on user store, SAML, multi-tenant org model. Good example - Zitadel https://github.com/zitadel has managed UI for orgs multitenancy, OIDC/PKCE supports, etc you can even partial glue RBAC to it
Subabase offers managed and opensource https://github.com/supabase/auth
Siding "MCP is dead, Skills forever" what bother me about all of them is planning to plug MCPs and rotate keys ... this start hitting the fan very soon
OAuth 2.0 Dynamic Client Registration (RFC 7591) https://datatracker.ietf.org/doc/html/rfc7591
https://modelcontextprotocol.io/specification/2025-03-26/bas...
Any comments greatly appreciated. Especially in multitenant saas and built-in "AI assistants" context
The spec handwaves around this talking about initial access tokens which a client would obtain first in order to register but the details are sparse and probably unworkable when we're talking about every end user being a client.
Ideally i would be able to specify an allowlist of redirect patterns so i could limit it to say, chatgpt or whatever else. But that would be a non-standard behavior so my IAM vendor isn't in a hurry to do it.
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?
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.
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.
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?
https://github.com/rorz/manual.email/blob/main/packages/db/s...
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?
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.
Once their revenue from Cloud services overtakes their core offering, bye bye Cloudflare free and so on.
I can't keep track of all the new things they do. Something-something-R2? Maybe?
> After investigation, we discovered that there was an issue in one of the Hydra migrations that corrupted the state of certain valid OAuth sessions, which resulted in the migration marking them as invalid.
Was this one of the open source migration files? While I'm no longer involved in the project, I'd be curious to know if it's been addressed upstream.
Not sure why they don’t just support DCR or CIMD for this too
Love em., greatest tech company of all time. One stop shop.
probably getting ahead of something the UK and some us states will require soon, as they already require from the sites behind cloudflare.
