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

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. [1]: https://tools.ietf.org/html/rfc6749 https://tools.ietf.org/html/rfc6749