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

OAuth for all

blog.cloudflare.com

Post reply on HN
Print view View original

41–50 of 174 posts

Re: OAuth for all

#41

Post by sandeepkd »

ZiiS wrote: post #37
sandeepkd wrote: post #4

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.

Re: OAuth for all

#42

Post by swyx »

utopiah wrote: post #35

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?

Re: OAuth for all

#43

Post by ok_dad »

sandeepkd wrote: post #34
ok_dad wrote: post #6

Earlier quoted context omitted.

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 thi…

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.

Re: OAuth for all

#44

Post by ok_dad »

usr1106 wrote: post #20
ok_dad wrote: post #6

Earlier quoted context omitted.

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.

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.

Re: OAuth for all

#45

Post by smw »

sandeepkd wrote: post #30
codebje wrote: post #5

Earlier quoted context omitted.

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.

Re: OAuth for all

#46

Post by cad »

zaptheimpaler wrote: post #12

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 ju…

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.

Re: OAuth for all

#48

Post by raxxorraxor »

zaptheimpaler wrote: post #12

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 ju…

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.

Re: OAuth for all

#49

Post by RVuRnvbM2e »

zaptheimpaler wrote: post #12

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 ju…

It's the worst delegated authorisation system except for all the others that have been tried from time to time.

Re: OAuth for all

#50

Post by tasuki »

cad wrote: post #46
zaptheimpaler wrote: post #12

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 ju…

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.

Post reply on HN