This sounds simple enough until you try to invoke an API function for a service like Twitter that uses OAuth for delegating user privileges to an app. With Twitter, OAuth sign-ins are used as signatures from the user, granting permission to an app to act on the user’s behalf. That’s the only way to get access to the Twitter API, and while that does make things more secure for Twitter users, it puts up a roadblock for developers using Apigee to model the very apps Twitter users want.
That problem has been solved this week, with Apigee’s launch of a public beta for a kind of “vouching service” that uses Twitter’s API, authenticating the user using OAuth on the Apigee user’s behalf.
“Effectively, what we’re doing is providing a key escrow, where we securely store a range of different keys for any given user, across a range of different API providers – Salesforce, Twitter,” explains Sam Ramji, Apigee’s vice president for strategy, in an interview with RWW. “And each app is going to have many users, most or all of these on behalf of any given app. It acts exactly as if the app had authenticated the user against those particular providers.”
When OAuth authenticates a user against one of these providers, he explains, it will respond with a particular permission, the form and format of which will be different depending on the provider involved. One example for Facebook may be a specific permission to post data to a user’s wall. “Posting to a wall against a Twitter API or a Foursquare API or a [Salesforce] Chatter API doesn’t make a lot of sense,” Ramji remarks. “So the granularity of the permissions have to tie back to the app. That’s why you’ll get the exact set of experiences as if you had authenticated the app [yourself]; Apigee is just acting as a broker on your behalf.”
Apigee’s API console, by contrast, continues to give what Ramji describes as “naked access” to the provider, anonymously. For a developer to use the Salesforce Chatter API, he would need to have – obviously – a Salesforce account. Such an account is authenticated using OAuth. So when modeling using Apigee, the developer authenticates through Apigee, which then validates his account through Salesforce. Once that’s done, the developer has “naked URLs running free” to Salesforce (if it can handle the metaphor).
If the developer thinks using Apigee’s OAuth API could make his code faster or more reliable, however, he can open a direct account with Apigee, and a private subdomain. Then the developer can use methods in his code to call the subdomain instead of Salesforce.com. Those calls will refer to the keychain for the user being authenticated. “It’s a simpler way to do tokenization across services,” Ramji says.
The Apigee console is free to developers; the company earns its revenue from platform producers who want to expose their APIs to a broader base. But in an astounding and separate innovation, it lets developers spread the word about Apigee by giving them the tools to make their own demonstration slideshows, and share them with others freely.
“What we did that was groundbreaking was, we realized that developers are social,” Ramji tells us. “So therefore, learning technology should also be social. By creating an interactive experience for APIs that you can then share – you can take any call that you’ve made in the console, and then you can snapshot it, hyperlink it, tweet it, e-mail it in a forum. You get a YouTube-like experience for an API, which is pretty weird. Usually technology is something that only happens in your mind, and it’s very theoretical. But being able to change an API experience into a YouTube experience, and then posting that in front of people, putting it in your Web site, throwing it in your Twitter stream, that’s been really helpful for developers sharing what they’ve learned.”
Article source: RRW http://feedproxy.google.com/~r/readwriteweb/~3/UW1sWX1-Z5g/apigee-adds-oauth-functionalit.php