OAuth'in with Drupal

## gistfile1.md

      
          Raw
        
        
              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

      
          Raw
        
        
              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