OAuth'in with Drupal

gistfile1.md

OAuth Research to get a sample running:

• Spec: http://oauth.net/documentation/spec/
• http://marktrapp.com/blog/2009/09/17/oauth-dummies
• http://drupal.stackexchange.com/questions/738/example-consumer-module-implementation-for-oauth
• https://gist.github.com/1065774
• http://drupal.org/project/oauth
  • http://drupal.org/node/296205
  • http://drupal.org/project/oauthconnector
  • http://drupal.org/project/oauthloginprovider
• PHP Samples
  • http://svn.php.net/viewvc/pecl/oauth/trunk/examples/
  • http://code.google.com/p/oauth-php/source/browse/#svn%2Ftrunk%2Fexample%2Fclient

---

Build out sample(s):

• 6.x: https://gist.github.com/2583645
• 7.x: https://gist.github.com/2308060

---

Javascript

• https://github.com/mashery/OAuth-1.0-JavaScript-Testing-Tool
• https://github.com/bytespider/jsoauth

OAuth_notes.mkd

OAuth 1.0 Protocol RFC 5849

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

Notes from OAuth 1.0 Guide

Example workflow

Request Tokens are only good for obtaining User approval, while Access Tokens are used to access Protected Resources

Security

The request signing workflow treats all tokens the same and the methods are identical. The two tokens are specific to the authorization workflow, not the signature workflow which uses the tokens equally. This does not mean the two token types are interchangeable, just that they provide the same security function when signing requests.

When implementing OAuth, it is critical to understand the limitations of shared secrets, symmetric or asymmetric. The client secret (or private key) is used to verify the identity of the client by the server. In case of a web-based client such as web server, it is relatively easy to keep the client secret (or private key) confidential. However, when the client is a desktop application, a mobile application, or any other client-side software such as browser applets (Flash, Java, Silverlight) and scripts (JavaScript), the client credentials must be included in each copy of the application. This means the client secret (or private key) must be distributed with the application, which inheritably compromises them.

It is important to note, that even though the client credentials are leaked in such application, the resource owner credentials (token and secret) are specific to each instance of the client which protects their security properties.

• RFC5849-4.6

  servers should not use the client credentials alone to verify the identity of the client. Where possible, other factors such as IP address should be used as well.

Authentication

• Note: this section provides a very nice interactive OAuth tool

Tools

• http://hueniverse.com/oauth/guide/authentication/
• http://term.ie/oauth/example/client.php

Potential open implementation of "facebook connnect" http://identity.mozilla.com/