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.
|
OAuth, OpenID, flow... (co: @glennpratt) |
|
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/ |
This comment has been minimized.
One more good link i had bookmarked - http://hueniverse.com/oauth/ intro to oauth