Select a language to translate this page!
Powered by Microsoft® Translator
We believe that people should be able to connect the devices, apps, and sites they choose, enabling richer integrated experiences in both. Nearly all Windows 7 PCs come pre-installed with Messenger, Photo Gallery, and the other Windows Live Essentials apps—just connect Facebook, LinkedIn, and other services to get a wide range of rich features like Facebook chat and social feeds in Messenger, photo publishing with people tagging in Photo Gallery, and all your contacts seamlessly available across Windows Live. And of course, you just have to do this once and your connected services roam with you to Windows Phone, Hotmail, and more.
Likewise in reverse, we know people want to seamlessly access Hotmail, Messenger, and SkyDrive from the other devices, apps, and sites they choose. Messenger Connect is the platform that lets site and app developers integrate SkyDrive, Messenger, and Hotmail into their experiences. Today, we're excited to announce new enhancements that will make that integration easier.
Since releasing Messenger Connect, we’ve gotten great feedback from our forums and from partners like WordPress, Sina Weibo, and Gigya about how developers want to use our APIs, and improvements we can make to the platform. Not surprisingly, developers want access to more integration scenarios via more modern standard protocols, in ways that are easier to program against, with a simpler experience for end users of their apps and sites.
Starting today, Messenger Connect is now evolving to provide:
OAuth is an authorization protocol that allows users to give one service or application access to their data hosted by another service or application without sharing their username and password between the two. The previous version of Messenger Connect used OAuth WRAP, an earlier incarnation of OAuth 2.0. With the new release of Messenger Connect, we support draft 16 of the OAuth 2.0 specification which is an IETF standards track specification used by a growing number of platforms across the web, such as Facebook, Salesforce, and Google.
With single sign-on, users are now signed in to Messenger Connect partner sites when they’re signed in to Windows Live ID-based properties like Hotmail or the MSN homepage. This means users don’t have to re-enter their credentials. To use this, all a partner site or application has to do is to ask for the wl.signin scope when requesting user consent, and afterwards, if the user comes to that website when they’re signed in to a Windows Live ID-based site, they will also be signed in to the partner site or application. Signing out of the partner website will also sign the user out of other Windows Live websites.
Another frequent request from developers is the ability for applications and websites to add events into a user’s Hotmail Calendar. This is especially useful for people like me who sync their calendar with their smartphone (Hotmail supports Exchange ActiveSync), so I can get a reminder about an event wherever I am.
We’ve also made changes to the end user experience to make it clearer what information applications are accessing when the user attempts to connect an application to their Windows Live account. In previous versions of Messenger Connect, when a user attempted to sign in with their Windows Live ID, they saw the following dialog:
This dialog was the same regardless of what information the application was trying to access, and you had to click on the “What will I share” link to see what information the application was actually trying to access. In the new version of Messenger Connect, we’ve separated the permission dialog from the sign-in dialog. Not only does this make it clearer what information the application is accessing, but it also prevents an extra sign-in requirement for users who are already signed in to a Windows Live ID-based site like Hotmail or the MSN homepage.
Below is what the new experience looks like. If the user is already signed in, they go straight to the simple one-click consent page:
We now also provide a version of this experience that looks great on mobile phones:
One of the other things we noticed is that our APIs were overly complex, supporting too many data formats, including AtomPub, JSON, RSS, and plain old XML, without adding a lot of value for them. This complicated our resource model and resulted in unnecessary data being returned by our APIs. We now have just one common format, JSON. And we’ve simplified our resource model as well. Here’s a code sample showing retrieval of a photo album, comparing the previous version of our API with the latest one.
Before: In the previous v4.1 version, here is the result returned in the Atom format when retrieving my photo albums:
After: In the simpler new v5 version, here is the same result returned in JSON:
In the past, our documentation has left developers with the impression that our Messenger Connect APIs are more complicated than offerings from other online services. We realized that we could provide better information about how to get started using Messenger Connect, who’s using it, and how they’re using it, including sample code. If you go to the Messenger Connect website at http://dev.live.com today, you’ll notice that we’ve updated the documentation to provide:
Again, we’re excited to be making it easier for developers to integrate Hotmail, Messenger, and SkyDrive into their apps and web services, which ultimately makes it easier for users to connect their Microsoft apps and services with the other stuff they already use and love.
If you build apps or sites, please check out our developer center on MSDN to learn more about Messenger Connect, and keep the great feedback coming. If you're a user, tell your favorite sites and apps how you'd like to see them integrate with Windows Live.
Lead Program Manager, Messenger Connect Platform
HUGE thanks for Calendar access. That's awesome!
It would be even better if developers could access the calendars and appointments and would be able to create new calendars.
Don't forget that you have to compete with Google. Please take a look at their Calendar APIs and give WL developers the same. THAT would be truly awesome!
The calendar access is GREAT!
Great to see you modernizing APIs, however, I've 2 comments:
1- Why can't you use what you advertise? I'm referring to the lack of single sign on using MConnect in the blog
2- No Upload API to skydrive yet?! Seriously!
3- Please work with WP team to give developers access to the logged in User, that would be THE success you are waiting for...
The possibilities look great, so I tried it on a wp7 device (inside a webbrowser control) .
I got two problems:
- the login page does not occupy by default the entire webbrowser control == it is not zoomed for a mobile device (you have to double tap in order to see the input boxes)
- once I get back to the https://oauth.live.com/desktop page, I get the an "unsupported_response_type" error
Are you still rolling out the update?
We've tested this on Windows Phone and have not experienced the issues you described below. Is it possible to describe how you're trying to use the API or even better post your code somewhere for us to take a look at?
Isn't there any managed wrapper around that stuff? Like the Live Framework or the Mesh API's in the past? The whole Messenger Connect sounds so web style, that it seems to be too hard to implement it in a client app on WP7 or the desktop using managed code. And please change that stupid name. What does this thing have to do with messenger? Nothing - it's an API for calender, contacts and skydrive. Live Framework was a much better name.
Awesome to see this happening. Now, how about proper API's to access SkyDrive from any device, preferably starting with Windows Phone 7 or 7.1 (aka Mango.)
It seems that the OAuth 2.0 feature doesn't work well when the redirect url comes from a localhost domain. I got this error message when trying to test the OAuth from a test app in VS, which runs with http://localhost address.
Oops, there was a problem
The provided value for the input parameter 'redirect_uri' is not valid. The value must be an absolute URL whose scheme is http:// or https://.
Here my test project (not much more than a Page + WebBrowser logging the visited url in background):
In case it helps:
- I am testing it from Italy, and I have Italian codepage on the device
- before testing the app, I had the "desktop" mode settings enabled in internet explorer (but I reinstalled the app several times, after having switched again to "mobile" setting)
- the problem exists both with the emulator (build LKG18, but compiled for 7.0) and my HTC mozart (latest may update applied)
- This is how I resolve the hostname:
Pinging oauth.wx.messenger.msn.com.nsatc.net [220.127.116.11]
- you need to add a correct client id
In case you need more info, add my skype contact
Thanks share this articles ...its a awesome
I tried your code sample and it worked for me with the following changes.
1.) Specified display=touch so the user gets the mobile friendly experience.
2.) Specify response_type=token which indicates your application is requesting an OAuth 2.0 access token
string client_id = "client ID goes here";
webBrowser1.Navigate(new Uri("oauth.live.com/authorize + client_id + "&display=touch&response_type=token&scope=wl.signin%20wl.basic&redirect_uri=oauth.live.com/desktop"));
More information on correctly forming OAuth 2.0 requests for Messenger Connect is at msdn.microsoft.com/.../hh243647.aspx
http://localhost is not a valid redirect domain to specify with OAuth requests to Messenger Connect. If you don't have a domain I'd recommend not specifying a domain when you registered your app ID and then using the redirect URI we provide for desktop & mobile apps - https://oauth.live.com/desktop
Are there plans to give developers deeper calendar access?
@nitricoxide, @kasparov, @ChrisLynch
Thanks for the feedback on the APIs you'd like to see us provide in the future. Can you give some examples of what scenarios you'd like to use these APIs in?
@Dare my app is a web app. how do I make it work with the desktop & mobile app redirect url?
For web applications, an actual unique domain name is required. For development, my recommendation would be to modify your hosts file (en.wikipedia.org/.../Hosts_file) to map the domain you specify to localhost or 127.0.0.1 so you can test on your local machine before deploying to your website.
@ Dare Obasanjo
My app would store and retrieve configuration data for itself. It would also store other data that the user would input, so that they could easily retrieve or restore their app settings and data. Right now, developers are stuck with using other cloud storage services (i.e. DropBox.)
I use Windows Live Messenger at all places, sometimes not only in my self computer but in Internet cafes and other computers. I use it also in my iPhone. That is my main communication tool.
But what happens is whenever I connect out of my computers I lose all the important messages. A great feature would be to save these messages on-line, at the Hotmail Box or at the Skydrive. That would be easy to do, saving my history in the cloud!
GTalk and Facebook do that already!
It is the only complaint I have about Windows Live Messenger! Thank you!
@Dare Thanks for the tip on modifying the host file. I'll try that. However, WL should consider adding support for localhost because it's so convenient during development and testing. And Facebook does support localhost, so there is no reason why WL can't.
Thanks for the feedback. This is a good suggestion.
Why haven't you blogged about the new Hotmail features in Wave 5? Some of them are AMAZING, like message pre-load.
WL should consider adding support for localhost because it's so convenient during development and testing. And Facebook does support localhost, so there is no reason why WL can't.
Any updates on that? You have one more vote to support localhost.