- 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
- PHP Samples
Created
January 11, 2012 17:25
-
-
Save christianchristensen/1595718 to your computer and use it in GitHub Desktop.
OAuth'in with Drupal
- 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
Request Tokens are only good for obtaining User approval, while Access Tokens are used to access Protected Resources
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.
-
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.
- Note: this section provides a very nice interactive OAuth tool
For the sake of argument: RESTful API Design: authentication
Noteworthy ebook (not yet reviewed): Apigee: OAuth: The Big Picture
Potential open implementation of "facebook connnect" http://identity.mozilla.com/
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
OAuth, OpenID, flow... (co: @glennpratt)