OAuth2 isn't a spec. It's merely loose guidelines.
I've worked with dozens of OAuth2 providers, and I am yet to see two implementations that are interchangeable. That's the point of a spec! All implementations required custom code. It's absolutely insane. We need a better way. Whatever replaces OAuth2 needs to be much more strict in how it should be implemented.
OpenID Connect fixes this exact problem. It fills in the gaps of OAuth2, where it often left the details up to the implementor, there is now a well defined process for verifying identity, and it's all done using IETF standards.
The definition of a spec is "an act of describing or identifying something precisely or of stating a precise requirement."
OAuth2 is really just a collection of suggestions. Here's some examples:
* What field should the token be passed back as?
* What are the token + auth URLs?
* Should there be a separate profile URL, or is user data passed back with the token?
* What field is the email address passed back as? The user's name?
* Are refresh tokens used? How?
These are just things I literally ran into today. There's hundreds more things like this.
And on top of that, pretty much every single OAuth provider requires custom code: http://passportjs.org/
I like OpenID efforts to making a OAuth 2.0 subset that works and is authoritative, but to be honest implementing OAuth dialect isn't that much of an issue.
now, having a single consistent user id across services beyond their email, that's an interesting problem to solve.
but for everything OAuth one can find out libraries in many languages.
I think you, like the article, is missing the point of OAuth; you seem to be thinking of OpenID, perhaps OpenID Connect which is built on top of OAuth. But some of your criticisms make no sense in the context of OAuth. Have you read OAuth 2.0's specification?[1] In particular, both you and the article presume there's a concept of a profile in OAuth … there's not. OAuth can be used to control access to a profile, certainly (and my understanding is that this is what OpenID Connect does, effectively) but at just the level of OAuth, you're controlling access to a generic resource. Concepts like a "profile" might make no sense.
> * What field should the token be passed back as?
It's passed in the Authorization header.
> * Should there be a separate profile URL, or is user data passed back with the token?
This is outside the scope of OAuth.
> * What field is the email address passed back as? The user's name?
"email address"? "user's name"? These are not concepts built into OAuth…
> * Are refresh tokens used? How?
In a grant_type=refresh request. It's in the spec.
I've worked with dozens of OAuth2 providers, and I am yet to see two implementations that are interchangeable. That's the point of a spec! All implementations required custom code. It's absolutely insane. We need a better way. Whatever replaces OAuth2 needs to be much more strict in how it should be implemented.