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

Why is OAuth still hard in 2023?

nango.dev

Post reply on HN
Print view View original

241–250 of 290 posts

Re: Why is OAuth still hard in 2023?

#241

Post by yrro »

infogulch wrote: post #16

What I don't understand is why all of these complicated SSO technologies like OAuth, OpenID Connect, SAML, LDAP, etc are integrated at the application layer at all. All these web applications should be using something like "Trusted Header SSO" [1], thus completely offloading authentication to the upstream reverse proxy (which does or should exist anyway) and then the whole problem vanishes at the level of the applica…

If you only want to put a dumb web app behind a proxy then use oauth-proxy. But OAuth caters for a lot more than that use case.

Re: Why is OAuth still hard in 2023?

#243

Post by NaN1352 »

OAuth is too abstract and that’s why it’s bad.

I’m not a backend guy, for a hobby php site I’m trying to get Oauth2 with gmail free smtp, and the token refresh part to run on its own and even with packages like Phpmailer there’s no simple working copy/paste examples, just loads and loads of bits and pieces and outdated examples and small print about Google changed this or that… I mean wtf is the point of having a package that is supposed to abstract OAuth if you still end up having to dig for hours and having to figure OAuth2’s flow in detail?

I’m so disgusted I figured maybe I’ll do the password with 2fa on that email acct and be done with it even though OAuth shpuld be the better option.

Re: Why is OAuth still hard in 2023?

#245

Post by knallfrosch »

remus wrote: post #12

It'd be interesting to hear about people who have had a good time implementing OAuth, as my experience is similar to that in the article. I've played with adding it to a few side projects and the process usually goes: 1. Read loads of docs, end up pretty confused 2. Find a library that seems to do what I want 3. Install this huge library full of opaque code doing...things 4. Have an impossible time troubleshooting is…

Yeah, pretty much. We have a hidden iframe silently refreshing tokens.

Don't ask me why, I thought the whole point of OAuth was that example.com was allowed to access identity.com. Instead, example.com opens a hidden identity.com iframe and does what do I know?

At my old job, users could specify their own IdentityProvider for their instance, which added a whole layer of complexity.

Now we have found out that a different team has implemented their side of OAuth completely wrong: Their device flow ("Open in app and enter 56474") doesn't poll automatically. Instead, user have to click "try now" manually. The whole auth is lost when the device restarts.

I'm not surprised Microsoft lost control of Bing because they implemented OAuth wrong for one of the services displayed there.

Re: Why is OAuth still hard in 2023?

#246

Post by jeroenhd »

smackeyacky wrote: post #192
codebje wrote: post #178

Earlier quoted context omitted.

Dynamic client registration is standardised ( https://www.rfc-editor.org/rfc/rfc7591.html ), the authorization code flow is standardised ( https://www.rfc-editor.org/rfc/rfc6749.html ). The device authorization flow is also standardised ( https://www.rfc-editor.org/rfc/rfc8628.html ). The preferred desktop app authorization process is described in a best current practice document ( https://www.rfc-editor.org/rfc/rfc8…

Just because the standards exist doesn't mean everybody follows them. Most and maybe all implementations have some crazy customisation. It makes the standards and docs almost worthless.

But that's hardly OAuth's fault. I can blame HTTP/2 cleartext because none of the websites I'm trying to access are working in my browser, but it's not reasonable to blame a generic protocol for not providing my niche when it's the implementations that are broken. Imagine complaining to the WHATWG because Microsoft decided to host an IRC server on port 80 and none of my browsers work.

In my experience, OAuth works great. Standard libraries Just Work, login Just Works, all you need is a URL (usually standardised) and maybe the configuration the service is expecting (i.e. the names of the permissions you're asking the user for). Usually, that's nothing special to set up. In some cases, particularly with huge "fuck you we're big enough to be the standard" vendors, there are some stupid hardcoded values and workarounds you need to deal with because they couldn't be bothered to use a library or document their flawed implementation.

I've set up a Keycloak server and authentication against it is super easy to set up. Copy-paste a domain, two generated tokens, and maybe a URL if .well-known discovery isn't implemented by the client, and that's it. Things can be easy, companies providing "OAuth" support just choose to make your life hard.

Re: Why is OAuth still hard in 2023?

#247

Post by jeroenhd »

lbriner wrote: post #236

As others have said, the main problem is that 1) There is too much flexibility which means that "name" might be "firstname" or "first_name" somewhere, which is why you need so many different implementations and 2) It is very hard to distill the relevant parts from the spec which covers all parts with equal vigour! We have the same issue with the UK Wiring Regulations, so they produced an "On Site Guide", which covers…

> 1) There is too much flexibility which means that "name" might be "firstname" or "first_name" somewhere, which is why you need so many different implementations

Names are funny because many implementations of standards make the mistake of presuming there's such a thing as a "first name" and a "last name" that make up a name. Or that the "last name" is the part you pass down to your family, and so on. If I see "first name" in any spec, I assume the spec is written solely for a small subsection of the population by someone who didn't put all that much thought into the spec. Not every service needs an email address, there's no telling what a valid username may look like, address specifications are basically plaintext strings even though many services pretend there's structure to them, and so on. Hell, most APIs authenticating against OAuth don't even need a username or user ID to function, all they need to provide is an access token.

Most fields have no business being standardised because they cannot be. OAuth is not a "log in with Facebook" standard, just like IPv4 isn't an "access Wikipedia" standard. If you host something that people authenticate through OAuth yet, you inevitably need to provide some kind of custom service properties.

Re: Why is OAuth still hard in 2023?

#248

Post by cookieperson »

haswell wrote: post #174
zmxz wrote: post #144

Earlier quoted context omitted.

> Forming an understanding of the basic concepts rarely happens in 10 minutes It happens when you're working and have sufficient experience, knowledge and practice when it comes to web, programming and HTTP. It's impractical, irresponsible and insane to have anyone other than a person with sufficient knowledge to work on application / API that supports OAuth and for person with proper expertise - the protocol is simp…

> it is true that majority of people I interacted with are having troubles understanding these protocols. However, what I can attest to is that they're also extremely underwhelming as people working in IT, with bad work habits and misplaced focus. It's impossible to explain or clear up the protocol to such audience because they lack much more when it comes to knowledge and discipline. In my experience, IT generalists…

Can you share any of your training materials?

Re: Why is OAuth still hard in 2023?

#249

Post by the8472 »

jcranmer wrote: post #75
thepasswordis wrote: post #61

Because the documentation is bad. Oauth is really simple: Lets say you want to use google as an auth provider. You do this: "Hey google who is this guy? I'm going to send them to google.com/oauth, send them back to example.com/oauth, and in the headers of the request include the word "Authorization: bearer" followed by a bunch of text" Google says "Oh yeah I know that guy, here I'll send them back to where you said w…

In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol. Actually go to the core RFCs for OAuth, and you realize that basically everything is implementation-dependent. You somehow register with the provider as a client (out of band and completely implementation-dependent). Then you ask them to log you in by sending a request to an implementation-dependen…

For a desktop application could use the password flow[0], no need to involve a web browser. Yeah, sure, you're now handing keys to the kingdom to that application, but if it's native software it could also have installed a keylogger or used an embedded browser component and extracted the data from there.

[0] https://www.rfc-editor.org/rfc/rfc6749#section-4.3

Re: Why is OAuth still hard in 2023?

#250

Post by pdobsan »

A while ago I wrote a small utility mailctl [1] to provide IMAP/SMTP clients (like msmtp, fdm, isync, mutt, etc.) with the capabilities of renewal and authorization of OAuth2 credentials. mailctl acts as a kind of smart password manager. In particular, access token renewal happens automatically in the background transparent to the user.

Since the program written in Haskell I also provided precompiled binaries to spare my potential users, most of them not Haskellers, from the complications of compiling it. The program have become moderately popular. However, little I knew how big can of worms I opened by releasing it to the public.

As many others pointed out, the two main reasons for the difficulties with OAuth are 1) the OAuth "standard" is terrible complex 2) the service providers' API documentation is an impenetrable obscure mess, always one step behind of the current working system. I have the feeling that the second one is not just negligence but might also be an intentional hidden lock-in mechanism by forcing the use of the vendors' ever changing API libraries.

[1] https://sr.ht/~petrus/mailctl/ also mirrored at https://github.com/pdobsan/mailctl

Post reply on HN