Oauth -- shall we start using this?

[Toshio Kuratomi]

On Mon, Mar 11, 2013 at 07:05:57PM +0100, Pierre-Yves Chibon wrote:
> * 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.
> 
You'd need a big token if you intend to use all of the api.  You wouldn't if
you only intend to use a portion of it.

The thing that we seem to be getting hung up on is that a CLI application
can potentially access all of the API of a single resource server and
potentially other resource servers as well.  What I would propose here is
that we utilize puiterwijk and my thoughts on emulating sessions to have one
big token per resource server.  But that token has a very limited lifetime.
That makes it inappropriate for scripting and cron jobs.  When you want to
make a shell script that runs on its own, you need to get a different token
that has more limited permissions.  That sort of token would have a longer
or perhaps indefinite lifetime (indefinite when you consider the presence of
refresh tokens).

> 
> Actually, how are the CLI supposed to work if we don't integrate oauth
> with goa?

There are several methods depending on how much we want the user to trust
the commandline app.  puiterwijk and I agreed that we could use the
"Resource owner password credentials" method -- this would require giving
the username and password to the CLI app which would then perform the
necessary calls to the resource server to get the access token.  It could
also be done using one of the other methods if you don't want to require the
user to trust the CLI app we write :-)

> 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.

This is pretty normal though.  I know that I've encountered this in both a
micro-blogging and a photo management GUI application in Fedora.  Hiding
this from the user in this case is also not a feature in terms of security.
It's only a feature in terms of convenience.  The ability of OAuth to hide
the access token when the user and client are on two separate machines run
by two separate entities (for instance, facebook wanting to use flikr photos
and you) is good for security but when the user is on the same machine as
the client we cannot actually hide the token from the user.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20130311/4e246fb9/attachment.sig>