Why does every OAuth2 provider work differently?

Question

This annoys me, and perhaps I'm simply getting it wrong, but it seems that just about every OAuth2 provider has it's own subtle nuances to using their services. OAuth2 is supposed to be a standard way of dealing with authentication, so why isn't it?

Answer 1

Well, if you're talking about the 4 flows offered, in theory, by OAuth2 (Authorization Code, Implicit, Password Credentials, Client Credentials), then you're right: most of providers do not offer the 4 flows (usually just the first 2).

My advice is to pick Authorization Code flow (if possible), because this flow is exact the same for all the big providers (Google, Yahoo, Outlook.com, etc).

What will change between them: the request parameters. So, if you write a generic code for the Authorization Code flow (request auth code, exchange it by a token), just switching the specific parameters for each provider, you'll achieve a re-usable code.

Trying to be more clear: you can use a OAuth2 class that will handle all the flow until you get a token.

Then URLs and request parameters will belong to provider classes, like Google, Yahoo, etc. Pass these classes to OAuth2 as parameter.

Answer 2

OAuth 2.0 is a protocol framework more than a protocol in itself. It allows for building other protocols on top of it. This is why there are many options to choose from which may complicate things a bit today.

Moreover, OAuth 2.0 itself does not even deal with user authentication at all (see: http://oauth.net/articles/authentication/), since it is not an authentication protocol but a protocol that allows for delegated authorization.

Yet several providers have been building their own extensions on top of OAuth 2.0 to deal with user authentication. There's also a standardized user authentication protocol defined on top of OAuth 2.0 in the form of OpenID Connect (http://openid.net/specs/openid-connect-core-1_0.html).

Hopefully in the near future more and more providers will migrate their OAuth 2.0 based user authentication protocol to OpenID Connect and we get rid of the myriad of variants that providers had to build previously when OpenID Connect was not yet standardized.