So far I can only find a name:password authentication mechanism in the TypePad API, has anyone seen/used an Auth token mechanism for TypePad like Google's or Flickr's, I thought it might be TypeKey but I've pulled a dry hole on that front as well.
A:
I'm a little confused by your question, so let me see if I can explain my understanding, and in so doing, at least try to help and/or clarify what you mean.
First, I assume you mean TypePad's Atom API, yes? If so, then that API doesn't use a straight username/password authentication mechanism, it uses a custom extension to HTTP authentication based on the WSSE Username Token (PDF). The WSSE mechanism has the client side of the API generate a random string and a creation timestamp, and then it hashes a concatenation of the the random string, the timestamp, and the user's password, and then it sends an HTTP header which contains the username, the hash it created, the random string, and the timestamp. The server then performs the same hash, compares the results, and grants or denies access. So the password never crosses the wire.
The best example of how to generate and use X-WSSE headers I've found is here:
http://www.xml.com/pub/a/2003/12/17/dive.html
So yes, the mechanism isn't like Flickr's whole frob mechanism, but it's also not a straight username/password mechanism.
delfuego
2008-09-18 00:52:24
It seems like there is a bit of a trade-off here... OK, you now get to hash the password+nonce+created and don't have to transmit the password over the wire, BUT now you have to store the customer's password in clear text in your database to be able to hash-and-compare again.I'd much rather store a hash of the password in the database, and send the password over the wire, but with SSL.Please correct me if I'm wrong :-)
opyate
2009-12-28 12:26:25
You're sort of right. You're right that you have to have a mechanism of accessing the user's password, but you're incorrect that that mechanism has to be clear-text storage of the password. At least one web property that has implemented the TypePad API server-side -- probably the biggest one -- reversibly encrypts all user passwords, and stores the keys to the encryption in a database that's logically and physically separated from the first. If the user DB is compromised, the attacker only gets encrypted passwords, not the real deals.
delfuego
2009-12-28 20:42:51
What I'll do is store the passwords encrypted with a public key, then read them back using a private key (initialised by sysadmin on app start-up). We already have a system in place for storing credit card numbers, so I'll just use that. The typical one-way hash (with salt) won't work in this case.
opyate
2009-12-29 10:25:35
Nevermind... I just gave the HTTP Digest spec a proper read: the client asks for a challenge, then the server sends the salt back in the response. The client hashes the password, then the server compares this with the stored hash in the database.I understand now that WSSE was an option for low-cost hosting peeps who didn't have HTTP Digest set up on their servers. HTTP Digest is not what this SO question is about, however :-)
opyate
2009-12-29 10:39:15
A:
@delfuego, thanks for the pointers above!
I did not know that TypePad had an Atom API as well as the XMLRPC API I was looking at. While way better than the clear text name/psswd that the XMLRPC mechanism has, WSS-username pattern still has the weakness that I'm trying to avoid - namely I do not want my users to have to give me their TypePad passwords so I can talk to their accounts in their behalf.
Compare this to the google gdata AuthSub model, here I have my users authenticate my service against their account with specific scope and permissions. My user is redirected to a google page to do this, and I get back a token that I store to use in future interactions with Blogger (for example) All I need do is register my application with google and verify my domain.
I noticed in the typepad docs that there is something called an API password but I still don't see that this resolves the need for my users to have to cough up a password if they want my service to post items to their blog...
jottos
2008-09-18 17:51:11
Oh, gotcha -- I see what you're trying to do, and definitely feel for you since there's almost certainly no way for XML-RPC to support that model. I'll run this question by the Six Apart guru I know well, and see if there's any hope.
delfuego
2008-09-18 18:25:12
+1
A:
Jottos, I just got the word from my Six Apart contact -- who definitely knows The One Answer to this -- that it's unfortunately not doable with TypePad and/or TypeKey right now. He said that the way to do this right now is to use the API password, which only gives your app the ability to use the API endpoint -- at least that doesn't ask the users to surrender the keys to the whole store.
Now that I know this, I wonder whether there'd be utility to creating a trusted store service that apps like yours could authenticate against and ask to generate the appropriate X-WSSE headers on a per-use basis. Using OAuth would make it pretty simple... hmmmmmm.
delfuego
2008-09-18 18:42:59