OAuth: the spec, the dance, and Drupal

Presentation from the 2012 Dallas Drupal Days

Slides

(Note: the post as follows is identical to the slides)

The Web: HTTP/1.0

  • Client <– –> Server
  • GET, PUT, POST, DELETE, HEAD, …
  • Headers

Auth experience

Example with Basic Auth:

curl -u "username:password" https://www.example.com/special

Auth experience

  • Session Auth (cookies) IETF RFC 6265
    • “free” with most web frameworks
    • A session is usually tied to one user account and is normally authorized fully or not.

Example with cookies holding state through a session:

curl -c cookiejar.txt https://www.example.com/login
curl -b cookiejar.txt https://www.example.com/special

Auth experience

  • OAuth IETF RFC 5849
    • “Valet key for the web” (limited access OAuth Token)
    • Scope access to resources

Example of a signed OAuth request:

<special signing sauce>
curl -v -H 'Authorization: OAuth
 oauth_consumer_key="zsQpwbL3AGRNV4272Xc8Msi3hxhQWGrS",
 oauth_signature_method="HMAC-SHA1",
 oauth_timestamp="1346887460",
 oauth_nonce="1548267549",
 oauth_version="1.0",
 oauth_token="wvokahqtGMLS5o4AvVvokGZaA9pZjBcW",
 oauth_signature="tvHRw2fLNxYE2FR62EfH6tAfBW4%3D"'
https://www.example.com/special

So what’s so special about OAuth?

Authorization has meaning

So what’s so special about OAuth?

  • Each client is assigned credentials granted by a resource owner to access a protected resource on a server
    • Note: Client <– (stuff) –> Server
    • Therefore the credentials granted to a specific client can be managed/revoked by the resource owner.
  • An endpoint(s)/HTTP resource(s) can be scoped (to limit its functionality)
    • “I give you (Ms. client) access to my API, but read only.”
    • “Access all of my public data (Mr. client)”
    • “(Mrs. Client) Is requesting access you your bank account, allow?”

Halt!

What about that guy on the internet (Eran Hammer) that was like “OAuth 2.0 sucks” !!rage quit!! ?!!

Agree or disgree … most importantly: he’s an expert and is prosthelytizing great information - Listen to him! (and read carefully)

The takeaway: dont throw the baby out with the bathwater and his commentary is directed at the 2.0 draft

Let’s Dance

Footloose dance

What OAuth looks like

Facebook Twitter AllPlayers

What OAuth looks like: Protocol workflow

faji: photo gallery site

beppa: photo printing site

What OAuth looks like: Protocol workflow

Access faji from beppa's site

Redirection to get access on faji

What OAuth looks like: Protocol workflow

Approve/Authorize faji to give tokens to beppa to access as you

Redirect to Beppa

What OAuth looks like: Protocol workflow

Ask again using temp tokens and get real live access tokens

Request from the API with real live access tokens

Technical pieces

Terminology

  • Consumer: client
  • Service Provider: server
  • User: resource owner
  • Consumer Key and Secret: client credentials
  • Request Token and Secret: temporary credentials
  • Access Token and Secret: token credentials

URL pattern(s)

(Related to protocol workflow)

  • https://provider.example.net/{initiate,request_token} (Temporary Credential Request)
  • https://provider.example.net/authorize (Resource Owner Authorization URI)
  • https://provider.example.net/{token,access_token} (Token Request UR)
  • http://consumer.example.com/{oauth_redirect,ready,…}

(Ref: URL patterns for Twitter, AllPlayers.com)

Refs

About Me