Is Yahoo! PlaceFinder an appropriate use case for OAuth?

Question

<context> I got frustrated yesterday and posted a flame question which was quickly (and appropriately) closed and deleted by my fellow SO cohorts. Yahoo! turned off its standard PlaceFinder API endpoint and replaced it with a paid service. That's not the part that frustrated me though, it was mostly the fact that they changed their access model to require OAuth. One of the closers of my question commented something to the effect of:

you didn't keep an eye on deprecations of API's you depend on, OAuth is better for users, suck it up.

While I could argue the facts of my API-watching by again blaming Yahoo for having broken links when they first announced the API deprecation back in October / November of last year, I think it would be more productive to try and turn this into an intelligent question. </context>

I have used OAuth. I like OAuth. Not only does it let you authenticate users and simplify sign ons to your application, it lets you ask for authorization to access that user's data from other apps. But PlaceFinder data is not private user data. It is for known place names and global identifiers (WOE ID's) that can be shared by everyone.

This morning I gave Yahoo! BOSS GEO my credit card information and started spiking up an OAuth API consumer to test it out. I started with DotNetOpenAuth, which I have used in the past. I read through Yahoo!'s OAuth guide and created a DotNetOpenAuth.OAuth.ServiceProviderDescription instance with all of Yahoo!'s OAuth 6.1, 6.2, and 6.3 endpoint URL's. I then went about trying to figure out how to use DotNetOpenAuth.OAuth.WebConsumer to hit the PlaceFinder API and start giving money to Yahoo!.

But it didn't work. I had to overcome a lot of cognitive dissonance, and in the end, either a limitation of the popular and widely-used DotNetOpenAuth library itself or a possible misuse of OAuth. When I finally realized that the BOSS documentation was separate from the BOSS GEO documentation, and found a C# code sample that worked to consume Yahoo!'s PlaceFinder API, I discovered where all of that dissonance was coming from.

Yahoo!'s PlaceFinder API, while it uses OAuth, does not require an Access Token to get at the API's endpoints or data. When you send a PlaceFinder request, you send all of your app's information (consumer key and secret), along with the timestamp, nonce, and signature to the PlaceFinder endpoint itself. When I used OAuth in the past, these elements were sent to the 6.1 endpoint to obtain a request token. You could then use that to authenticate / authorize the user (6.2) and obtain an Access Token (6.3) to make further requests.

Here's the limitation in DotNetOpenAuth that I can't overcome so far, so if I'm being ignorant and doing it wrong here please tell me. In the sample C# code on Yahoo!'s site, they are not using DotNetOpenAuth. Instead they have an OAuthBase class that you can use to generate a nonce, timestamp, and signature. But they send empty strings for the access token and secret. I tried doing this with DotNetOpenAuth, but it won't let you construct any requests with a null or empty access token.

So the question: Is this an inappropriate use of the OAuth standard? If not, is there a limitation in the DotNetOpenAuth library that makes it impossible to send unauthorized requests to endpoints other than for a RequestToken (6.1)? If the answer to both of these is no, how could you use DotNetOpenAuth to request PlaceFinder data without having to send an access token or secret?

Answer 1

There's two types of oAth that yahoo uses. One requires a key, one doesn't. You probably want the one that doesn't for general API use. Just add the secure protocol http:// -> https:// and then place /public/ in an appropriate spot of the old url like

https://somePartOfURL/public/otherPartOfURL

Answer 2

This is a great question. I think oAuth provides BOSS developers with two benefits

1. Since you sign up for BOSS once and can then use that key for multiple services, the BOSS team wanted to have the flexibility to offer more services that needed tokens in the future. Starting with oAuth right from the get go allowed that flexibility.

2. The team wanted to ensure that keys are not sniffed out during network communication. Since requests are signed and actual keys are not passed, we can ensure that no sniffing happens.

Regarding your question on DotNetOpenAuth, I recommend asking on the BOSS Y! group (http://tech.groups.yahoo.com/group/ysearchboss/) since we have a number of folks who have written in C#, VB.Net who can advise you. In fact it is well known that the VB.Net oAuth library (http://oauth.googlecode.com/svn/code/vbnet/oAuth.vb) has some issues with it.