[wp-xmlrpc] Any interest in OAuth?

[Joseph Scott]

On Jun 17, 2008, at 1:23 PM, Joe Cheng wrote:

> OAuth isn't my first choice due to the weird configuration  
> experience--
> we're a client app, it's strange to direct users through a website,  
> and
> IMHO is something to be avoided unless fine-grained permissions and
> revocation makes a lot of sense.

Agreed, it's a little bit odd.  I went through basically that same  
process when enabling the Flickr features in MarsEdit.  I leave the  
app to approve it on Flickr's site.  I didn't mind, but I can  
appreciate the concern of loosing the user by requiring them to leave  
the app (even if just for a moment) to approve the token.  And there  
are similar concerns I'm sure with websites that would need to do the  
same thing.

However, I don't think that process needs to be a bad one though.  If  
they understand what they are being asked to do, hopefully it  
provides more comfort than blindly entering in their username and  
password.

If you really wanted to keep them in the app you could embed a web  
control that loads the needed site for them to approve the token.   
Yes, I'm pretty far out on the limb now :-)


> But the current state of the art is completely unacceptable--passwords
> passed in the clear. If there was a way for us to auth more securely
> without violently changing the configuration experience, we'd be VERY
> interested.

I see this as two issues currently.  Sending sensitive data is solved  
by using SSL, I believe at this point that is the only real solution  
to that problem.  This isn't something that WordPress itself can  
enforce at this point because people are free to run it on non-SSL  
web servers.  On the WordPress.com side of things, I'll see if we can  
do more to direct people to the https xmlrpc end points.

The second issue is one of application authentication.  Entering in  
the same username and password every where; Flickr, Google Docs, Mars  
Edit, Windows Live Writer, any other web site that can post to your  
blog, is just not a good idea, even if that app does in turn send the  
sensitive data over SSL.  This is something that SSL can't solve.  It  
looks like something that OAuth can help deal with.

I'm open to other suggestions that will help address this.


> Obviously SSL is one fix but not an option for most WP users. (However
> I would love to see WordPress.com RSD point to https, which seems to
> already work.)


Using SSL on WordPress.com work, and I believe there are some folks  
working on making more of the site use it.  I'll find out exactly  
what the plans are and see if advertising the https address can be  
added to the list.


> Another is X-WSSE[1] but it requires the server to know the password,
> and I seem to recall Joseph saying WP only saves a hash.

Yeah, covered that with the other HTTP auth stuff:

http://joseph.randomnetworks.com/archives/2007/09/19/http-basic- 
authentication-a-tale-of-atompub-wordpress-php-apache-cgi-and-ssltls/
http://joseph.randomnetworks.com/archives/2007/09/19/http-basic- 
authentication-a-tale-of-atompub-wordpress-php-apache-cgi-and-ssltls/ 
#comment-240685


> Maybe we could do X-WSSE but encode the hash instead of the password?
>
> [1] http://www.xml.com/pub/a/2003/12/17/dive.html


As long the database isn't required to store something that is  
essentially a plain text authentication string.

--
Joseph Scott
joseph at randomnetworks.com
http://joseph.randomnetworks.com/