I have implemented OAuth servers and also OAuth clients because our integrations go both ways: some parts of our systems rely on 3rd-party services and other companies rely on us as well. The take away from my comment is that even if the software specification is clear (I gave RFC 6749 as an example) some engineers will disregard the instructions and make something completely unexpected. The majority of developers expect good quality software from big companies with massive engineering teams, but people who have the opportunity —or should I say misfortune?— to work with them realize software engineering quality is often an illusion.

Whatever the intentions may have been, it is definitely not the case that OAuth pushes complexity to authorization servers. My audit checklist for OAuth clients is fairly long.

As someone in the early stages implementing Oauth2 for the first time, I would be interested in seeing that list, if you don't mind sharing.

Agreed, I'd love to read that blog post.

Or Book/booklet, I'd buy that as I'm sure many would.

Indeed, there are some people when it comes to best practices, that I respect more than industry standards as they are usual best practices that will be standard tomorrow.