Eran Hammer

I went on a similar journey but for OpenID Connect. While the spec is fantastic https://openid.net/specs/openid-connect-core-1_0.html#Overview, I found the same thing to be true - very little explanation of why. For example, it's very clear how each flow works and therefore how to implement, but not clear why there are so many of them. While researching and building my own implementation I eventually ran into IdentityServer3 https://identityserver.github.io/Documentation/ which had a nice intro video explaining things clearly. I also quit building my own at that point, since their offering is very well done and using the same stack as the rest of our software. I wouldn't say the docs are a good resource, but they helped a bit. There's also a version 4 now, though the documentation looks about the same.

Also not a good resource, but acceptable: Pluralsight. There is one straight up OAuth course to go over all the basics and then quite a few language/framework specific ones, e.g. how to implement OAuth in Node/ASP.NET/etc. The OAuth course was dry but had some decent information - but I did quit halfway through it because of IdentityServer, so take that with a grain of salt.

And yes, it sure does feel more complicated than it has any right to be. There's a good read here https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529?gi=84094c5b3f24 by the once-lead-author.

I really do recommend checking out IdentityServer4 though, unless you're implementing this…

I am currently an IAM engineer and can I just throw out there how much I hate OAuth/OIDC, I work at a large org and have to integrate with dozens of different vendors and applications and not a single one has the same way of doing OAuth because to quote the spec, wait it isn't a spec it is a "framework" we have to remember that, under interoperability it says

> OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable implementations.

Don't get me wrong, OAuth is still better than WS-Fed and what we had before but we really need to come up with a real standard and spec for authentication, because OAuth/OIDC is a joke. It isn't just me either that thinks this one of the authors of the OAuth spec said as much[1]

Can anyone tell me what their experience with OAuth has been, or have they been able to get it to work across multiple different systems. I would love to believe it is just my org, but it seems like the entire identity space is a clusterfck.

[1] https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

An argument I've heard against TLS is that it's easy for clients to get wrong. In some cases, client code needs to directly check that the certificate matches the intended domain, and forgetting to do so makes TLS worthless because an attacker can just use any valid certificate. In other cases, certificate checking runs into some problem, and an inexperienced developer finds a "solution" on StackOverflow to just disable certificate checking, which, again, makes TLS worthless. In other cases, a client might make a valid TLS request to the wrong server (either by mistake or due to some other attack).

With OAuth 2, any of these problems will leak your bearer token, meaning than an attacker can act as you until the token expires.

With OAuth 1, you're typically going over TLS anyway, but even if an attacker knows the contents of all requests, they won't be able to act as you because they still won't be able to sign any future requests.

Edit: I just dug up the blog post I've read that describes most of the points I made above: https://hueniverse.com/oauth-bearer-tokens-are-a-terrible-idea-1a300fd12e13

This is a collection of the author's favourite technologies/gripes, not a useful proposal. A large number of errors can be found by considering that it'll have to talk SMTP on the back end.

I'll only point to some "highlights".

OAuth isn't nearly secure enough (http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/) for your e-mail (which, don't forget, gives access to everything via password resets). Let's just ignore the part about third-party access.

Encoding everything as UTF-8 is nice, but breaks the first time some idiot mail client puts Shift-JIS encoded Japanese in the Subject: field. Without any charset marker, obviously. (This goes right back to the "where does the mail come from?" issue.)

IMAP has a THREAD extension (solving #4), a SEARCH extension (solving #9 and parts of others), and all sensible servers support IDLE (http://en.wikipedia.org/wiki/IMAP_IDLE). It also supports downloading MIME parts separately, solving the part of #7 that can actually be solved (again, you'll have to accept mail.)

> I wonder why someone hasn't already transitioned Twitter to a publish-subscribe architecture internally, and used a bunch of queues to buffer the impact of load spikes ( a slow tweet is not the same as a dropped tweet! ).

c.f. Starling : http://rubyforge.org/projects/starling/

As others have pointed out, it's not the messaging that's hard, it's the ad-hoc services-- friends-of-friends timelines, keyword search/subscriptions, etc. that are hard to scale and are what is bringing twitter down:

http://www.hueniverse.com/hueniverse/2008/03/on-scaling-a-mi.html

Which, to jzawodn's point, is actually really similar to what FriendFeed is doing under the hood, and doing it well.

Here is my list of solo developer blogs. Usually they are on topic. This does not include personal blogs I follow that happen to be developers.

@mdo (Bootstrop) - http://markdotto.com/

Keith Cirkel - https://www.keithcirkel.co.uk/

Coding – Corbin's Treehouse - https://www.corbinstreehouse.com/blog

Aaditya Purani – Ethical Hacker - https://aadityapurani.com/

Ben Balter - http://ben.balter.com/

fulldecent - https://privacylog.blogspot.com

Orange - http://blog.orange.tw/

Cocoa with Love - http://www.cocoawithlove.com/

Mark Otto - http://markdotto.com/

Moxie Marlinspike's Blog - http://www.thoughtcrime.org/blog/

hueniverse - http://hueniverse.com/