14 DAY TRIAL // The next iteration of Messenger Connect will be designed to play nice with version 2.0 of OAuth 2.0 by default, Microsoft promised. The Redmond company has a presence at the Internet Identity Workshop (IIW) this week in Mountain View, California, USA, an event which brings into focus open web standards such as: Open ID v2, OAuth, Activity Streams.
The start of the IIW offered an opportune moment for the software giant to offer a taste of Messenger Connect Next, with the promise that more details will follow in the coming months.
“The Windows Live team is pleased to announce our support for OAuth 2.0 in the next version of our developer platform, Messenger Connect, which allows developers to build sites and applications that use data from the Windows Live network,” revealed Dare Obasanjo.
“This development builds on our existing commitment to open web standards shown in the current version through our implementation of ActivityStrea.ms, OAuth Wrap, Portable Contacts, & OData.”
Messenger Connect already offers developers the possibility to leverage OAuth, and taken into consideration the company’s latest announcement, the same will be valid for the next version of the standard.
Of course, OAuth 2.0 is the successor of the OAuth protocol, which, according to its creators, is designed to focus “on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.”
Just as it is the case with OpenID, OAuth is about providing access to third-parties to specific content. However, there’s a fundamental difference between the two, and it’s related to identity.
With OAuth, web developers can take advantage of an API which permits them to offer services to users, but without requiring them to share their credentials.
“OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user),” reads an excerpt of OAuth’s description.
“It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.”