oAuth enables a user of an application such as a widget to link that application to an external service, without the application storing, or having access to, any user credentials.
For example, using oAuth, a Photo Widget could get access to a user's Flickr account, without the Photo Widget storing the username and credentials of the user, just an authorization token that cannot be reused for any other user or service. To set up the token, the first time the Photo Widget is installed, the user is prompted to go to Flickr, log in there, and agree to grant the widget access to the service.
Currently very many widgets store user's account details in widget preferences as this is the only means of user access they have that doesn't involve the user constantly re-entering account details to get at basic functionality. In some environments this may not be a significant risk, depending on how preferences are stored and accessed; however in many cases the fact that a widget can impersonate the user (logging on as the user, rather than with a token) causes issues for trust and auditing.
Because many widgets are small local applications offered for remote services that use different user accounts, oAuth is a very important and relevant technology. Which is why, for example, it has been a major task in the oAuth and OpenSocial/Gadgets community to integrate the technology.
((Note also that last I heard oAuth was going to IETF for standardisation))
S On 23 Feb 2009, at 11:02, Thomas Roessler wrote:
On 23 Feb 2009, at 05:15, Jon Ferraiolo wrote:OAuth is a technology that authorizes someone to do something. For example, an OAuth server might authorize you to cast a vote in an election. Regarding authorization, in the most common case of W3C Widgets, you would most likely use something like an OMTP/BONDI policy file or some sort of platform-specific (maybe implicit) policy to control authorization instead of OAuth. My thinking is that you can ignore OAuth for now.I think you're conflating policy and protocol here -- OAuth is a way to share an authorization token (and really not much more); it doesn't tell you how to write your authorization policies.If I were on the committee, I would push to finish Widgets 1.0 as quickly as possible, and then put OpenID and OAuth on the list for things to consider for Widgets 1.1.+1OAuth seems most relevant to XMLHttpRequest level 2, and much less relevant to the widget specs.
smime.p7s
Description: S/MIME cryptographic signature
