Application-specific passwords

[rekado]

Background

OAuth requires an OAuth client to be registered with the server before any user can be asked to authorise the client to access a resource. This model makes sense for a centralised service provider, because authors of OAuth client applications only have to register their application once. For a decentralised service like MediaGoblin where there are many independent installations, the requirement to register a client becomes an obstacle.

Example

If I had a web application that allowed my users to link their MediaGoblin accounts in order to upload pictures through my web application to their MediaGoblin collections, I would have to register my application as a client on every MediaGoblin installation that I want to support. This doesn't scale.

Proposal

OAuth doesn't seem to be designed to cover this use case. Hence I propose to implement application-specific API tokens.

If a MediaGoblin user wanted to allow my web application to act on her behalf through the API, she would generate an API token for my web application and store the token with her account on my web application. My application can then use this token to perform uploads as the MediaGoblin user until the user decides to revoke the token.

A user could thus grant external applications limited access to their account by generating a new application-specific password. The application could authenticate against the MediaGoblin server by providing the user's username and the application-specific password.

(Something like that is used by Google when two factor authentication is enabled for Gmail and one needs a simple password to authenticate one's email client with the server.)

As I need something like that, I volunteer to work on implementing this if it turns out to be a good idea.

[Jessica Tallon]

Okay so I don't believe this is an issue as we have ​dynamic client registration which allows a client to register itself via an API. It's very simple and there is no limit on how many times you wish to use it, typically every instance of a client should register.

The documentation ​here should help you easily set up this. Additionally ​PyPump is a library in python which has dynamic client registration built in and it functions with mediagoblin 0.7.0 or higher.

Let me know if you still think this is a problem, otherwise I think this can be closed as wontfix (or invalid?). Either way I think this can probably be closed.

[Christopher Allan Webber]

I'm closing this because it sounds like the functionality is already implemented via the mechanism Tsyesika described above. Your rationale makes sense I think! But I think probably Tsyesika is right that it's closable. Let us know if not!