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

61–70 of 174 posts

Re: OAuth for all

#61

Post by bogdan »

ok_dad wrote: post #44
usr1106 wrote: post #20

Earlier quoted context omitted.

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

You're right. Crazy how we ended with so many different implementations.

Re: OAuth for all

#62

Post by kjgkjhfkjf »

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.

Re: OAuth for all

#63

Post by niyikiza »

willtemperley wrote: post #18
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…

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.

there are some emerging mechanisms for offline verification that don't require AS in the OAuth WG. (I'm working on one of them)

Re: OAuth for all

#64

Post by niyikiza »

necovek wrote: post #13

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?

Means you can basically host your own AS

Re: OAuth for all

#65

Post by zigzag312 »

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.

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

Re: OAuth for all

#66

Post by cassianoleal »

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.

> 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.

Re: OAuth for all

#67

Post by fmbb »

jurgenaut23 wrote: post #17
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…

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?).

> I always thought this complexity was there for some good reason (security?).

It's just design by committee.

Re: OAuth for all

#68

Post by notpushkin »

badgersnake wrote: post #57
RVuRnvbM2e wrote: post #49

Earlier quoted context omitted.

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.

Re: OAuth for all

#69

Post by sarreph »

kjgkjhfkjf wrote: post #62

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.

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...

Post reply on HN