The OAuth WRAP work may fit your requirements. See the Google group here: http://groups.google.com/group/oauth-wrap-wg
and the spec here WRAP-v0.9.7.2.pdf<http://oauth-wrap-wg.googlegroups.com/web/WRAP-v0.9.7.2.pdf?gda=eB-Si0QAAABFB7PFAFiVedPtjcqT8uuI7mMcD5C_1HDpGD17Hv6NBhidFvlYqd_ZjmG9h9kh5-pV6u9SiETdg0Q2ffAyHU-dzc4BZkLnSFWX59nr5BxGqA> and here is a token format: SWT-v0.9.5.1.pdf<http://oauth-wrap-wg.googlegroups.com/web/SWT-v0.9.5.1.pdf?gda=YPRQ8kMAAABFB7PFAFiVedPtjcqT8uuI2mPoSSzjrdCd0_4fDoXLv9F2tzlQ33RhT1wW8BFYO1QytiJ-HdGYYcPi_09pl8N7FWLveOaWjzbYnpnkpmxcWg> Microsoft is deploying OAuth WRAP in the Access Control Service in Azure and Google is working on using it as well for enterprise use cases. OAuth WRAP is being contributed to this work group with the hope that the capabilities are included in the work produced by the IETF. -- Dick On Sat, Jan 9, 2010 at 9:36 AM, Jeff <[email protected]> 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] <oauth%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/oauth?hl=en. > > > >--
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.
