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

141–150 of 174 posts

Re: OAuth for all

#141

Post by dumah »

dust-jacket wrote: post #130
aroman wrote: post #110

Earlier quoted context omitted.

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

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.

Re: OAuth for all

#142

Post by mwwaters »

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

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

Re: OAuth for all

#143

Post by pseudosavant »

luma wrote: post #138
willtemperley wrote: post #18

Earlier quoted context omitted.

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.

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.

Re: OAuth for all

#144

Post by fheisler »

aeneas_ory wrote: post #86
khurs wrote: post #84

Earlier quoted context omitted.

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? An…

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

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!

Re: OAuth for all

#145

Post by OkayPhysicist »

the8472 wrote: post #90
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…

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.

Re: OAuth for all

#146

Post by fragmede »

chrisan wrote: post #122
fsfasfd wrote: post #120

Earlier quoted context omitted.

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…

A password manager can both take care of remembering unique passwords and allow privacy options

Good luck getting people to use one! Even when they do, the UX is a nightmare.

Re: OAuth for all

#147

Post by kordlessagain »

kspacewalk2 wrote: post #114
clickety_clack wrote: post #112

Earlier quoted context omitted.

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.

There's a way to do auth with just email as well. Any good service will have a "I forgot my password" flow. Instead of using passwords, why not use tokens you email them gated by a 2FA challenge?

I have both Google and Github Oauth flows added to this idea in code, and it works great for my purposes. Prior to coding agents, I wrote the code by hand and went over it a few times to ensure it worked and was safe (for the email token thing at least). I even wired up the Oauth stuff myself, without an agent. It's not hard.

With agents, it's super easy to audit this and also deploy services using them, so I'm not sure why any arguments here mention how hard it is nowadays. It's not hard, but it does expose what site a user is logging into. That's just a easy function for the user though, with known risks.

With Google email, if I use a site with email logins, Google STILL knows I used them. It's just in my email instead of a logfile that I authenticated to a site. I would note that as long as the token is alive, dependent on the provider's choices, Google doesn't know I'm going back again, and has no idea what I'm doing on the site. I'd trust Google over anyone else about this, even Github (as related to Oauth to avoid the nitpick that has been common here recently).

I would hardly call this a "security nightmare" (as someone else said, not you) as Google only knows someone is authenticating to a given URL which they've vetted (a little) during the setup process. Same for Github. If you don't like Oauth, or feel that then every site someone uses should provide an email login fallback.

Re: OAuth for all

#148

Post by kordlessagain »

sharts wrote: post #118
kspacewalk2 wrote: post #114

Earlier quoted context omitted.

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

If you sign up on a site with your stock email, this is a risk as well. And for retrieving lost logins, you still have to have an email in there. Why does it matter if I use a burner Gmail account for this and don't they already provide spam protection?

Re: OAuth for all

#149

Post by adeptima »

Mixed fealings cause the full context should include plans on both Authorization and Authentication flows at least withing Cloudflare ecosystem. No github examples

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

Re: OAuth for all

#150

Post by adeptima »

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…

the original sin of internet - it’s not secure, and for many it’s not the bug it’s a feature to make money or gain power. all nested layers to cover up previous fails. example - nonce, state, encryption bumps in oidc/oauth2.1
Post reply on HN