I finally managed to put some time on my OAuth application... I released a proof of concept and would like your opinion on the matter. Basically, it is a Android OAuth broker as discussed above.
On another note, I red about the OAuth AccessorSecret which could be interesting in situation similar to the one discussed. However, I noticed that not many service providers support the AccessorSecret describe here http://wiki.oauth.net/AccessorSecret The application is located on GitHub and can be found here: http://github.com/novoda/oauth_for_android I still need to work on the documentation a bit for easy install - brightkite is not working due to the lack of support for oauth_Callback on their side. Jaiku does not work either as they don't support callback. MySpace and twitter should work. Any comments are welcome. Thanks Carl On Aug 26, 7:29 pm, "Carl H." <charr...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
