Don't you see some contradiction between your two sentences? You're attempting to recommend something that supposedly "magically" works so people using it don't need to understand the details about authentication. Seems like the quickest way to end up with all sorts of problems.

I read it as meaning "Don't implement it yourself if you're not ready to go deep down", not "do not use already battle tested".

I read it as "don't bother with details, just use this thing here that does a lot of other things but happens to have a lib that might do it".

I think it's absolutely a good idea to use battle tested code, but you need at least working knowledge on what you're doing to apply it properly. Same thing applies for crypto in general: you generally don't implement it yourself, you generally use battle tested code, but you need to understand what you're doing. The idea that you can eliminate any of these steps and have something working properly is wishful thinking.

Haha, good point.

Like forgetting about disabling Meteor's 'autopublish' and 'insecure' packages that are enabled by default.

A bunch of different "identity as a service" type products seem to be getting more prominence (Auth0, Stormpath, and Ping Identity come to mind), too. The selling point of these seems to be that you as a developer don't want to spend all your time doing figuring it out and doing it right, so offload it to somebody else.

OAuth is for authorization, not authentication.

That may have been the intent, but in a (very, very) large portion of cases the developer simply wants a way to verify identity claims. That is, verify that you are who you claim to be. 3rd party identity providers (Facebook et. al.) are a convenient way to do this, for both the user and the developer (maintaining your own passwords is a pain etc). It's coincidence that these providers choose oAuth for this, but you still end up with oAuth for identity, not auth'z.

The phrase "verify identity claims" just means "authorize". There has never been a version of OAuth that would authenticate an identity.

edit: Sorry, it's easy to understand how "verify identity claim" does sound like authentication. What it means for OAuth, is that a system authorizes access based on delegated authentication. So "verifying an identity claim" is binding a local authorization event to a remote authentication event. Or something.

OpenID Connect [0] is "an interoperable authentication protocol based on the OAuth 2.0 family of specifications." Note this is a different protocol from OpenID 2.0.

[0] http://openid.net/connect/faq/

Yes, OpenID Connect is a protocol that builds on the authentication features developed from previous versions of OpenID, and merges it with the authorization features defined via OAuth.

It is all laid out fairly clearly in this comment on the original blog post, for example: http://developer.telerik.com/featured/oauth-has-ruined-every...

"Alternatives" such as OpenID and Persona flopped though. So it is not like there is much choice anyway AFAIK.

It's more a problem of people who know what they're doing being annoyed by idiosyncrasies than people who don't know what they're doing not knowing what they're doing.