The other question that often arises is how does the JS widget securely "authenticate" itself to the hosts in order to dynamically retrieve access tokens and secrets. I suppose you could force the JS to be dynamically generated and use a one-time-use token in the JS widget code to bootstrap into the access token & secret request, but then you lose the benefits of caching.
Your server-to-server protocol could easily leverage OAuth in it's "two-legged" mode.
Dick's mention of WRAP may help as WRAP does not require signing instead relying on SSL and bearer tokens. I don't know if that will meet your security requirements or not.
Thanks, George On 1/9/10 12:36 PM, Jeff wrote:
--Hello: I'm new to this group and oauth. I've done a lot of searching, but I still have not found an answer to my questions. I'm am currently working with a product that offers RESTful web services. The current registration method is contracting with a partner organization and then issuing them a ID and secret signing key. Requests are made by the partner application to our server using an Amazon S3-like HMAC signature over stuff like the HTTP method, URL path etc. This can be used for server-to-server requests made form the partner organization's system to our server to update product information, as well as via pre-signed links returned to end users. They can click on these links to invoke services, but only for a limited time. Also, with the resource being part of the signed string, the link is useful to access only a specific resource. They can't change the URL to get more than was authorized. We are looking into providing Dojo Javascript 'widgets' that partner web applications can easily place in their web pages. The widgets then will make use of the cross-domain JSONP mechanism to invoke the web services and also present the results. I do not wish to make the private signing key known to the Javascript widget due to security reasons. I've been looking into oauth today to see if it may buy me something. Using a more standard protocol seems like a good thing for interoperability, but I'm having trouble understanding why I keep finding references to people either making use of the consumer key and secret within Javascript code or referring to using some kind of oauth proxy to do it securely. I'm still looking into this, but I figured I'd ask why that is necessary. For the Javascript widgets, using its customer key and secret, I would like the partner web application to obtain an access token and secret and provide then and the customer key to the widget when the page loads. Then, the Javascript widget can issue requests without knowing the consumer secret. And at some point, the access token will expire. Is there any reason this cannot work? I could see it might be necessary for every partner organization to actually have two consumer key/secret pairs, with different levels of authorization. One will allow the partner organization to update product information and whatnot on our server, while the second is used generate access tokens which cannot be in turned used to make any modifications etc. Any thoughts would be appreciated. I apologize in advance for any totally noob questions. :):) Thanks! Jeff
You received this message because you are subscribed to the Google Groups "OAuth" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
