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 |
POST |
HTTP Basic Authentication or request body | Request body |
|
GET |
Request URL | Request URL | |
|
POST |
Request URL | Request URL | |
|
POST |
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.
Luís Gonçalves 