On Fri, 2013-03-08 at 14:07 -0800, Toshio Kuratomi wrote: > So in the past week a bunch of us have been talking about API Keys, > OAuth, passwords, and other means of managing authn and authz in the > web apps that are up and coming (specifically mentioned were copr and > datagrepper). > Puiterwijk has put in some time reading the OAuth specifications and > on Friday he walked me through how OAuth is supposed to work. I'll > give a summary of his talkl here and then we can kick off some > discussion. > > OAuth is a standardized method for a user to grant access to resources > that they own to people and things that are not themselves. Currently > this is being used to allow a user to control the access to data and > actions that may be performed on one web service by another web > service. The concepts and mechanisms can be used in any situation > where the user wants to limit what the software they are using can do > on their behalf. Here are some of my thoughts on the question. My main interrogation is "What does it bring us?" (© Seth), more precisely, what does it bring us compare to an approach where each apps implement their own token mechanism (cf copr). Advantages: * One central place where in case of problem all the token associated with someone can be removed * Potential easy/easier integration in gnome-online-account which already integrate google's oauth mechanism * Standard mechanism * Possibility to restrict a token's action - Well this can already be discussed. It has been made clear that it is a all or nothing mechanism (a bit like when installing an app on an Android phone, you have the choice between giving this app access to your contact, the gps... or not using the app). Meaning, since most if not all our tools will be able to perform most of the action possible on the website, it's pretty much coming back on having one big token to use the APi of the website. Disadvantages: * One more application to develop, deploy and maintain, application rather sensitive if we want it to work with all the oauth client. * One more highly critical application this is will store the API token for everyone and thus if broken the attacker can do a whole bunch of stuff on a whole bunch of webapp. * Implementation are rather specific and one implementation might not work with another one. * It means we have to all agree on this and actually implement it :) (which might be the hardest part considering we've not even agreed on a framework :-)) At the end, too me the killer feature is the integration with gnome-online-account (goa) as this is clearly something we would like to have. All our CLI could then rely on this and call dbus to retrieve the api login and tokens (example for the google oauth[1]). In addition, to my understanding, gnome-online-account stores its information in the session's (gnome-)keyring, so we would have some level of protection. Foreseeable problem, integration in other desktop? I have no idea if there is an equivalent of goa for KDE, LXDE or XFCE, Mate & co. Actually, how are the CLI supposed to work if we don't integrate oauth with goa? The cli spits out an URL that the user should visit? But then the oauth server will have to give the user the api login and token which the user will have to put somewhere on the system himself, which already looses one of the interest of oauth which is that the user (normally) doesn't see these information. So to me, I'm not sure yet if the pros outweigh the cons. I see two majors gain: - potentially easier integration in goa - easier cleanup in case of security breach but the cost of developing, maintaining and keeping secure such app are also very high. I guess it comes down to, are we really going to use the fine-level permission system oauth brings us? And if so how (cf my remark above)? This is the state of my current thoughts :) Pierre [1] https://github.com/derflocki/gnome-shell-google-calendar/commit/b07e3bf77fcbbd9e25c23a74a898c2e641e9cc7c _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
