Getting Started with OAuth 2.0

Preface

I’ve been working with web-based APIs since 1999, building SOAP-based web services for internal IT applications and helping thousands of developers using Google’s REST-based APIs for Google Calendar, Picasa Web Albums, YouTube, and more. Each of these APIs has required authorization from users to act on their behalf. Developers using these Google APIs were initially required to use proprietary technologies like ClientLogin and AuthSub. If these same developers wanted to integrate with APIs provided by Yahoo!, they needed to use Yahoo!’s BBAuth. The use of these proprietary authorization technologies made it challenging to build applications using APIs from multiple providers.

The development of OAuth 1.0 reduced many of the headaches for developers and allowed them to use a single authorization technology across hundreds of APIs on the Web. However, OAuth 1.0 came with some challenges as well—cryptographic signatures and limited definition of how to use it for authorizing applications not using a server-to-server web application flow. I’m delighted that the standardization of OAuth 2.0 is nearly complete, as it provides an authorization protocol that’s easy to use both for these types of applications and for a variety of other use cases.

Perhaps most exciting is the upcoming standardization of OpenID Connect—a protocol built on top of OAuth 2.0 to enable using the same identity to log in (authenticate) to multiple applications. While I’ve worked with hundreds of developers ...