Hi George: Thanks so much for your response.
On Jan 12, 10:38 am, George Fletcher <[email protected]> wrote: > One of the issues with OAuth is that it requires messages to be signed > with both the consumer secret and the access token secret. So I don't > think just giving the consumer key to the JS widget is going to work. > This is why Open Social uses an "OAuth proxy" for it's widgets. With the signing requiring both the consumer and access token secrets, I can see why oauth 1.0a will not work for me. > 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. In my scenario, it will be the partner web application that authorizes the JS to access resources of the application's choosing. The end user does not authorize anything and does not need to know this is even going on. We are trying to limit access to proprietary information to which the partner organization has subscribed, not access an end user's resources. I guess in a sense the partner organization is the 'user' that authorizes, and our server provides the resources to only properly authorized requests. Knowing which partner organization authorized the request is important for tracking and providing contracted customized content. The specific end user is not important. As far as flow goes, once the webapp obtains a token to authorize the JS, I was thinking of then providing it to the JS when the page is loaded. Something like: <div dojoType="x.y.MyWidget" resource="/resource/path" authz="SomeToken"> </div> This example is very generic, but the widget is being told what resource to obtain and authorization to do so. For our current HMAC signature scheme, this works out as the resource is part of the signed base string used to authorize the request. Much like S3, the signature has an expiration time built into it, and it cannot be used to access a different resource. The page on which this widget is loaded is also somewhat resource specific by the time the user has drilled down to this level. This is not a long lived RIA, but rather existing web pages with our widgets embedded to make it easy to add additional functionality. > Your server-to-server protocol could easily leverage OAuth in it's > "two-legged" mode. That makes sense. > 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. It seems there is some divisiveness in the oauth community regarding WRAP. I'll take a closer look and see if it makes sense. Perhaps that bearer token can be provided to the JS. I've got no problem with signing myself. :) Cheers, 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.
