Sorry for the delay on this, I had deadlines to meet which made me drift away from my original OAuth application. Comments inline:
<< Yes, a service provider should be able to unauthorize a consumer easily. >> All devices will use my consumer keys to connect to service providers (I wish I could do this differently). The user will choose the services they want to use and authorise my consumer key adequately. This is where I am a bit twitchy as if one device end up being pirated, the service provider might cancel the key instead of the key for that specific user. << Android provide some way for one software module to identify another, before cooperating with it? >> Yes and it is what I am currently doing. Each call to my application will ask the user if he authorises application X to use MyOAuth to do an OAuth call on his behalf. He can answer by "always", "yes", "no" or "never". I keep track of all applications calling each service provider and let user pro-actively choose how to handle malicious calls. Application X does not require any OAuth information. It calls MyOauth application and receives the output of that call. As such it does not care about any OAuth signing and so forth. I also intend to have each application register itself with its own consumer key. Further to the above fine grained security, I am also taking a similar approach to Google in regard on its way to access OAuth from Android. It is apparently possible to access Google's OAuth infrastructure from within your application if the following is part of your application's manifest (the manifest defines which permissions/services/activities your application runs): <uses-permission android:name="com.google.android.googleapps.permission.GOOGLE_AUTH"> This is not very well documented and unsure how well it works but the idea is similar. If an application uses OAuth calls from MyOAuth, the application is required to have my own OAuth permission in its manifest. As such when installing the app onto the device, the user is requested to accept the installation while knowing it will access OAuth info. Throughout my experience within Android, several applications access OAuth based service providers. I just want to have it centralized in one provider in order for the user to have better control of which app does what. I will get back to my OAuth app next week and hopefully will have it documented online shortly. This will give a better idea of what I am currently doing and happy to accommodate any comments. Cheers, Carl On Aug 21, 6:08 pm, John Kristian <jmkrist...@gmail.com> wrote: > Rather than assign a different consumer secret to each device, I > suggest each device get a unique access token secret using OAuth; that > is by asking the user to authenticate to each service provider and > authorize the device. (The token secret and consumer secret are > separate elements in OAuth.) > > Yes, a determined user can find his own token secret. That's OK. The > problem is allowing someone else (an attacker) to use the secret. To > prevent that, applications should discourage the user from finding his > token secret, and hide the secret from other, possibly malicious > applications running on the same mobile device. The latter needs some > infrastructure, to prevent applications from seeing each other's data. > > For a consumer copied to users' mobile devices (or desktops), a > conventional consumer secret isn't very useful because it isn't really > secret. Assume attackers will know it. You might as well publish it, > as Google did. Look elsewhere for assurance that consumer software is > trustworthy. I expect any healthy software market will have some way > to help users trust the software they use. > > Yes, OAuth doesn't help fight piracy. (I mean the use of unauthorized > copies or imitations of licensed software.) > > On Aug 20, 6:38 pm, Sunir Shah <su...@freshbooks.com> wrote: > > > Sorry, the original proposal as I understood it was that every > > application gets a consumer secret for each mobile device. Presumably > > you could arrange this by cooking the binary every download with a > > different consumer secret. This is impossible in mobile environments > > with centralized distribution (iTunes, AppWorld). However, in those > > environments, this isn't really a problem. > > > My first reaction was that there is no way to avoid piracy, since if > > Pirate Alice downloaded the app, she could post it on the Internet and > > anyone (i.e. Bob) could use it. However, I realize now that isn't the > > case, since you can monitor the use of the consumer secret, and if one > > secret seems overly used, you can destroy it disabling all pirates. > > Hello Windows Genuine Advantage. > > > However, I would add in response to your suggestion, you should not > > rely on the premise that it is hard for the user to find their token > > secret since it is so easy to retrieve with common reverse engineering > > tools. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
