I've been doing some work lately using an OAuth-enabled API for both web-based consumers and heavyweight clients, and I met a number of folks at IIW last week with concerns similar to my own. Many people are looking at phone-based applications that fall into this same category.
With Google's recent experiments in this arena (see a couple threads back) as a starting point, I think we should start working out an official extension to OAuth that can better serve its usage in this non-website mode. There are a couple of considerations, some of which Nathan has brought up already but I want to collect here. I had initially wanted to reply to that thread, but as I'm new to the list, GoogleGroups won't let me do that. *shrug* The first is that of the consumer key/secret. The existing OAuth spec works on the assumption that the consumer will be on a secured server someplace and out of the user's hands, and can therefore be trusted (at some level) with its own secret. This obviously doesn't work out on a heavy app, since the key and secret would have to be packaged with the app itself in the traditional model and could easily be copied out and spoofed in a different app. One solution is to have a known catch-all value such as Google's anonymous/anonymous that all desktop apps use. If we were to go this route, I would suggest a standardized key/secret set be chosen such that all service providers can deal with it appropriately. I personally don't like anonymous/anonymous, but maybe desktop/app or unknown/client or something of that nature instead? I'm not really sure. Whatever keywords are chosen to fill the role, this set would have an implicit callback URL of "oob" (as per the Rev A addition, if I understand the changes properly), and the service provider would be able to dole out an appropriately frightening message letting the user know that the SP can't directly verify the application and that they should be really sure when they hit that button. Alternatively, we could have the individual clients themselves register for a unique consumer key, but it doesn't provide for unique identification and I don't see what this mode buys us over the already-unique access tokens that these apps would be getting. Next, we have the problem of client identification. Since we can't rely on the consumer key/secret to uniquely identify the application, the app should be able to identify itself, somehow. I like the Google approach of the name, and I propose that we actually have oauth_app_name and oauth_app_description keys for a short name and longer descriptive text, both sent by the app. Obviously, since they're being passed along by the app itself they can be spoofed trivially, and the SP should have text explaining something to that effect. But it would at least allow a user to say "well, I did just click a button in an app named Foo, and this is asking me to let something claiming to be Foo in, so it's probably OK". I would also suggest that the name/description pair be allowed only with the above "desktop app" key/secret, since all other consumers should be otherwise recognizable. Though allowing for registration of a name an description at the time of consumer key generation is probably a good best-practice for the overall user experience. Third, there's instance identification. We should give the user some way to differentiate between several instances of a given application that they may have installed or used in different locations. Even with the above name/description extension, a user returning to a list of authorized tokens will be presented with identically-named keys to a set of arbitrary strings. As a first step, service providers could allow for the user to set a freetext tag on each token at the time of authorization, and we should specify some guidance as to how that could play out. However, the client itself can likely offer some reasonable identifying information, such as a hostname, address, or the like. I propose that we have an optional attribute called something like oauth_app_instance that the client can fill in with something vaguely human-identifiable and hopefully differentiateable between instances. Finally, there's the problem of letting the client know that the token has been signed by the user and it's OK to continue. There has been some great brainstorming on this already, and I'd like to see it continue to develop into a set of best-practices. With Rev A's use of confirmed callback registration, we might see a lot of these ideas break. I'd also like to throw in that there could also be some kind of polling-mode added to allow an app to check if it's been authenticated yet. I'm not sure I totally like this approach, as it opens the door to a number of problems such as a rogue client continually polling for a token. This mode could be limited to a time-window or be rate-limited to temper this form of attack. It may be a reasonable alternative in some circumstances where the browser-dance isn't quite as integrated. Are there other considerations that are unique to the heavy client environment? Are any of the above pieces incomplete or unnecessary? Or should we try to develop another protocol to address this space and let OAuth be purely focused on website-to-website, which is what it's really good at. Thanks to everyone that I met at IIW, and I'm looking forward to further discussion. -- Justin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
