Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> So, what we've learned is that OAuth2 is not a single thing, and that it is too complex.

OAuth specifies multiple authorization flows, each one including independent risk mitigation steps.

In my opinion OAuth2 is not "too complex". It's a subject matter that has intrinsic complexity, but one which isn't that high to be blunt.

Of course people who are oblivious to the subject and just glance at it from a distance might be tempted to dismiss it entirely as too complex. This is indeed a recurring problem in software development circles, where typically developers are too quick to criticize existing work because they don't understand requirements, are oblivious to the problem domain, and do not understand how the problems they don't understand are solved. But this doesn't mean the problem domain is complex or too complex.

There is a reason why this sort of walkthrough is very useful: those who are oblivious to the subject and just glance at it from a distance have a way to walk through the requirements and the happy flow in a easy-to-digest way. Hence the comments that now OAuth2 is actually not that complex, it's the RFCs that specify it that are the problem.



OAuth's biggest issue is that unless you are regularly working with it, you'll probably forget most of the details once you're done implementing it. Similar story with regex for me, it's not that complex, but when I'm building queries a couple times a year at most, I end up forgetting it mostly. It's not surprising that most folks don't understand it, even if at one point they did in the past.


There are one page regex cheat sheets you can print out and put in your workspace. Then you simply consult the cheat sheets.

Unfortunately oauth cannot be compressed into a cheat sheet.

But yeah, oauth is absolutely something you forget right after using it and have to bootstrap every time you touch it.


> Unfortunately oauth cannot be compressed into a cheat sheet.

What's so hard about a specific authentication flow?

You have a user, a client app, a resource service, and an authorization service. You have a sequence of requests that send data back and forth. The end result is a token that client apps can send to a resource service. What bit requires volumes to understand?

Take a minute to check RFC6749. All authorization flows in there require between 2 to 6 pages to fully define. Is this too much info to parse?

https://datatracker.ietf.org/doc/html/rfc6749


You casually gloss over the hardest part of oauth (the sequence of requests made and the reason why they exist), which is the part no one remembers.




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

Search: