Actually, I like API keys myself. Simple and easy. Now API keys are ideal for cases where the user wants to change her password for her account, but her API key still stays the same and continues working for whatever client app is using it ....... actually Merchant Services sites work like this, or at least the ones I have implemented clients for ...... commonly the HTTPS form post includes 3 key-value pairs for MerchantID, UserID and User PIN. Hey, if it is good enough for Credit Card processing, it should be OK for my REST services!
Now what about the case where API keys are inconvenient for the end client user. For example, I have a Gianduia Cappuccino app where the user goes to a site, logs in and works away in his Cappuccino app with occasional REST requests to GET and manipulate serverside data. I guess we could store his userid and SHA-hashed password locally in the Cappuccino app and send the user id and SHA hashed password in two of the headers with every HTTPS REST request ..... is that common practice for this scenario? -Kieran On Mar 19, 2010, at 11:01 AM, Mike Schrag wrote: > i'm a fan of API keys, personally ... most "web 2.0" sites use them and it's > pretty straightforward to hook up. > > ms > > On Mar 19, 2010, at 10:44 AM, Kieran Kelleher wrote: > >> First, Wonder's ERRest.framework rocks! Thank you again Mike Schrag! .... >> and that is not my first time saying that in the last couple of days :-) >> >> Second, I would like to get some opinions on REST authentication approaches. >> There seems to be a plethora of approaches out there. >> >> Probably the "easiest" for us WO devs is to make the user call a https login >> URL first to authenticate with userid, password and if successful, hand them >> back a response with Session cookie and just use https and existingSesson in >> cookie in our ERX route request handling for the duration of the session. >> While easy for us, this might be a little inconvenient for the client >> developer though since they must now manage their session key and handle >> retries if the session has timed out, etc. >> >> So, if I were trying to get really simple (for the client/client-developer) >> stateless REST authentication, whereby the client did not have to maintain a >> session and every request has the authorization aspect, then what are the >> best approaches? Anyone have any hands-on experiences to share? >> >> The simplest approach seems to be the API Key, but it seems a little >> insecure ..... like a permanent session. For example these guys use an api >> key and, if I am not mistaken, it seems they use it over HTTP, so any >> traffic sniffer could pick it up: >> http://www.campaignmonitor.com/api/method/campaign-create/ >> Nevertheless this is obviously the easiest way for a client to interoperate >> I would think..... and if done over https, then it should be both secure and >> easy for a client implementation? Thoughts? >> >> Then you look at Amazon's authentication. That seems like a very secure >> solution? Any thoughts? >> http://docs.amazonwebservices.com/AmazonS3/latest/index.html?RESTAuthentication.html >> >> BTW, the java implementation for generating the ever-changing Auhtorization >> code for AWS Auth can be found at: >> ERAttachment/Sources/com.amazon.s3.AWSAuthConnection.addAuthHeader(HttpURLConnection, >> String, String) >> >> So, thoughts, opinions? >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >> >> This email sent to [email protected] >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
