I got an email the other day from Pedro Félix, asking for my thoughts on an OAuth scenario that he was wondering about and discussing with Howard Dierking. As Pedro and I talked, I learned that he had a really interesting problem on his hands. Basically, he wanted to create an OAuth 2.0 protected service that called an OAuth 1.0a protected service (e.g., Twitter). So, what he had on his hands was a bunch of clients, tokens, services, and two different protocols that do things similarly but w/ slightly different names. Very confusing stuff.
To begin making sense of all this, it's helpful to list out what we know:
- Pedro wants to call the Twitter API from his own API.
- The Twitter service is an OAuth 1.0a Resource Server (RS).
- Twitter has an OAuth 1.0a Authorization Server (AS).
- The Twitter service naturally only trusts it's own AS.
- Pedro's service is an OAuth 2 RS and an OAuth 1.0a Twitter client.
- Pedro has an OAuth 2 AS.
- Pedro's service naturally only trusts his own AS.
- The Web app that calls Pedro's service is an OAuth 2.0 client and must submit Access Tokens (ATs) emitted by his own AS (not Twitter's) when calling his service.
- The Resource Owner (RO) is a Twitter user and will authorize Pedro's service to call the Twitter API to modify their data.
- The RO authenticates to Pedro's AS using Twitter's OAuth 1.0a AS.
- Pedro's AS asks the RO to authorize the third-party client to access his service which in turn will access Twitter's.
With these basics in mind, have a look the the following picture that presents an overview of the actors involved and flip through the following slideshow to see the message flow: