Hacker News new | past | comments | ask | show | jobs | submit login

A year ago we implemented OAuth for 100 popular APIs.

Our experience was exactly like OP describes: https://www.nango.dev/blog/why-is-oauth-still-hard




I worked on a system that implemented OAuth against maybe a half-dozen APIs. None of them were the same. It's a series of rough guidelines, a pattern, not a spec.


The extra annoying part is that learning each auth is basically a single-use exercise. Sure, you get better from 0-5 but from 5-100 it's mostly just grumbling and then trying to forget whatever esoteric "standard" was implemented.

Source- done over 300 system connections. Save the straight API keys, they're all special and unique snowflakes.


Almost the exact same sentiment as yours, but from an earlier conversation, and it really stuck with me.

“… one of the principle issues is that it's less a protocol and more a skeleton of a protocol.”

https://news.ycombinator.com/item?id=35720336


See also: EDI / EDIFACT / ANSI X12. It was supposed to standardize the way businesses exchange data, but every company implements it differently so integrations take forever, and there's an entire of middlemen offering solutions to make it faster.


The RFC reads very much like a spec and not like a rough guideline. What are you talking about when you say guideline?


I've read the RFCs several years back and they did not feel clearly written, not like a protocol spec. Maybe it was just me. The reality is each OAuth implementation is unique. Almost no two are the same.


All the problems mentioned in the blog post are due to the providers not following what the spec clearly said.

If you have an example of where that's not the case, I would also love to hear as I work in this area (perhaps you're thinking about how OAuth does not specify at all how authentication happen? But that was a good call, OAuth 1 did and it was too limiting... also OpenID Connect is pretty widely adopted now, and it fills that gap well).


"Clearly" is relative. If all these providers are having problems with the spec... what does that tell you?


What that tells me is that people who cannot read and understand a specification (or willingly ignore what the spec says) are implementing it anyway. I claim the spec is completely clear on all the points raised in the blog post. You can't just handwave that away without specifically telling what point was unclear.


Just imagine if we had these problems with TCP!


It's how people follow something that says what it is.


The RFC is not what people actually implement.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: