Allow application to manage its list of tokens

Bug #316733 reported by Markus Korn
6
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
Low
Unassigned

Bug Description

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

Revision history for this message
Leonard Richardson (leonardr) wrote :

Can you describe some use cases?

Changed in launchpad:
status: New → Incomplete
Revision history for this message
Markus Korn (thekorn) wrote :

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

Changed in launchpad-foundations:
status: Incomplete → New
Revision history for this message
Leonard Richardson (leonardr) wrote :

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?

Revision history for this message
Markus Korn (thekorn) wrote :

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

Revision history for this message
Leonard Richardson (leonardr) wrote :

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.

Revision history for this message
Markus Korn (thekorn) wrote :

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.

Revision history for this message
Leonard Richardson (leonardr) wrote :

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.

Revision history for this message
Francis J. Lacoste (flacoste) wrote :

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

Changed in launchpad-foundations:
importance: Undecided → Low
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.