Allow application to manage its list of tokens

[Markus Korn]

Please add API methods to access the list of tokens on https://staging.launchpad.net/people/+me/+oauth-tokens. It would also be nice if there could be a method to revoke authorization of a token.

Markus

[Leonard Richardson (leonardr)]

Can you describe some use cases?

[Markus Korn (thekorn)]

Right now I see two use cases, apart from just getting a plain list of tokens:
 * I would like to know the date of creation and the access-level to a token which was written to a file on my local system (matching the access-token)
 * I also would like to check if there is an active token for the same consumer and with the same access-level before creating a new one

And as a bonus I would like to revoke the authorization of a token, for example in a unistall script of an application to clean up unused tokens

Markus

[Leonard Richardson (leonardr)]

Here's where I'm coming from. This sounds like a privilege escalation attack waiting to happen. If you can get a list of tokens, you know what other applications the person is using. This is privileged information by itself, but it could also be used as a first step towards getting other OAuth tokens.

The uninstall use case makes sense. It might make more sense to make the user go through the web browser to revoke a token. But I don't really see a security problem with letting an application revoke its own token.

I'm also okay with giving access to metadata about the OAuth token used to make the request, and other tokens for the same consumer.

Checking for an existing active token is useful but also opens up privacy questions. Since you don't have a token yet, you'd make the request without signing it. This would allow you to impersonate various clients to find out if the user has a token for that client, simulating the effect of a full list of tokens.

How satisfied would you be if we published a collection of OAuth tokens that contained tokens for the current application only, and allowed you to delete the token currently in use?

[Markus Korn (thekorn)]

I'm not sure if I entirely understand this whole OAuth and access-level system and I'm also no security expert. But in my opinion this is a typical usecase for the "write-private-data"-access-level, so a user would only be able to see/change his own tokens. Similar to the Web UI, where you also can only manage your own tokens.

In case I'm missing something, your last suggestion sounds perfect to me.

Markus

[Leonard Richardson (leonardr)]

Certainly the user should only be allowed to see their own tokens. I'm concerned about what could happen if we allowed web service application A to see or revoke your credentials for web service application 2. You might get applications spying on or uninstalling each other. Admittedly this is unlikely to happen for Launchpad clients, but that's the kind of case we consider when thinking about security.

[Markus Korn (thekorn)]

Good point, did not see this one. So allow to delete the token currently in use seems to be the only solution here. If you also give access to the metadata of the active token, I'm all good.

But this unfortunately does not cover the use case where I would like to know if there is a active token for a consumer with the same access-level *before* creating a new one, I understand that this is hard to achieve when you do not allow unsigned requests.

[Leonard Richardson (leonardr)]

Here's how to solve that problem. When the user gets sent to the webpage for creating a new token, we say:

It looks like you already have some authentication tokens for application "Foo". Choose one of these tokens to give the application you're running now:

* Token 1 (read all data)
* Token 2 (write public data)
* Token 3 (write all data)

Or create a new token:
  * Read public data
  * Read all data
  * Write public data
  * Write all data

Like all other information we don't trust the client to handle, we present this information in the web browser.

[Francis J. Lacoste (flacoste)]

I like that proposal and file a separate bug about it: bug #317900.