OAuth 2.0 and Social Identity Providers

OAuth 2.0 is an authorization framework with increasing support on the Web as the major social identity providers – namely Facebook, Google and LinkedIn – use it on their APIs.

Well… some of them actually “use it”: even though OAuth 2.0 has been an RFC for more than 1 year, some of the APIs are not fully compliant with the spec. Sometimes this isn’t a big issue because there are SDKs and widgets which hide the actual OAuth flows. But if you need to use the OAuth endpoints directly you’ll probably find yourself doing custom code for each provider. In the remainder of the post I’ll explore the differences on Facebook, Google and LinkedIn APIs regarding OAuth.

OAuth 2.0 defines different authorization flows, but I’ll focus on the authorization code grant flow, which might be the most common. This flow uses both the authorization and the token endpoints. As far as the authorization endpoint is concerned, all of the 3 providers stick with the spec, but things are different when we get to the token endpoint, as summarized in the table below. I’ve included links to each provider’s documentation page.


HTTP Method

Client Credentials Location

Request Parameters

OAuth 2.0 RFC


HTTP Basic Authentication or request body Request body


Request URL Request URL


Request URL Request URL


Request body Request body

From the 3 providers, Google is the only one that is doing it right. I’ve been working on a scenario where using the available “login” widgets and SDKs wasn’t suitable and I couldn’t have a nice, by-the-book, OAuth 2.0 consumer and just configure the endpoints. Oh well…

It’s worth mentioning that Google is also aligning with OpenID Connect, which means you get additional parameters on the authorization endpoint and a standard userinfo endpoint.