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.
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?).
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)
Classic Cloudflare, for all, works well, not too expensive... but, and consequently of all those positive attributes, positioning itself at the center of everything.
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.
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.
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.
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
>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.
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.
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.
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.
It's a privacy nightmare.
To cover the myriad of (sometimes downright stupid) requirements that large enterprises have.
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)
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.
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.
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.
probably getting ahead of something the UK and some us states will require soon, as they already require from the sites behind cloudflare.
Once their revenue from Cloud services overtakes their core offering, bye bye Cloudflare free and so on.
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.
Wait so what do you think their core offering is?
I can't keep track of all the new things they do. Something-something-R2? Maybe?
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.