Oauth -- shall we start using this?

[Pierre-Yves Chibon]

On Mon, 2013-03-11 at 11:28 -0700, Toshio Kuratomi wrote:
> 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. 

hm, atm we have one CLI per application, tbh, I'd rather keep it this
way.

>  What I would propose here is
> that we utilize puiterwijk and my thoughts on emulating sessions to have one
> big token per resource server. 

So we're back pretty much on 1 token / application (pkgdb, copr...)
which would be the approach we would take if we implement token w/o
oauth.

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

Meaning, we need to have a way to generate a token for the user (where
he can choose which permission he associates with the token), no?

> > 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 :-)

But then that's pretty much what we are already doing with for example
pkgdb-cli and to me that defeats a bit the point of tokens, where would
we use them then?
I my idea, tokens are there to replace the use of the password which if
intercept gives you access to more than the token itself (ie: with your
password I can change your password, with your api token I can change
the ACLs on your package)

Pierre