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
Attachment:
pgpK8efWzRRkq.pgp
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
