Oauth -- shall we start using this?

[Pierre-Yves Chibon]

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