|joar, nyergler, tsyesika
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.
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.
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.