[wp-xmlrpc] OAuth alternative

Allan Odgaard m123ixd02 at sneakemail.com
Wed Jun 18 09:16:05 GMT 2008


I am repeating myself, but just to make it clear how I would prefer  
this granular security to be handled:

If Bob wants Flickr to post to his blog, he logs into his WP  
installation and on the user page there is a button called “Generate  
API Access Key”.

By clicking the button, WordPress will respond with something like:

     Username: Bob+0000001
     Password: d41d8cd98f00b204e9800998ecf8427e

Bob can then enter this into Flickr, MarsEdit, Google Docs, Ecto, etc.  
and for all practical purpose, this appears as just another user, but  
WordPress will know that this user is a restricted Bob (so posts  
coming in from Bob+0000001 are published as from Bob).

The benefit is that _everything_ will work with this system from day  
one, because no change needs to be done to MarsEdit, Ecto, Flickr,  
etc. and there is no need to phase out the existing authentication  
system (as one of the letters in the OAuth thread suggested).

If it is a common task for users to provide web applications with an  
API key, I can see justification for automating that, and OAuth is a  
protocol for this. Though I don’t think it should be done by  
introducing a completely new protocol for applications to authenticate  
with the blog because then in a year we will have two authentication  
schemes. One offers granular security, the other does not. Some third  
party clients will support only one of these two systems, some both.  
Some blogging systems will likewise only support one of the two. The  
safest will be for everything to support both, so how exactly did this  
help making things more secure? Rather, we just added unnecessary  
extra complexity to the XML-RPC system, and thus an extra burden on  
everyone writing an XML-RPC client or server implementation.

Keep it simple…



More information about the wp-xmlrpc mailing list