A month and a half ago, Microsoft announced that they had added XMPP to their Windows Live APIs. That means that any Jabber client could connect to MSN using our favorite open IM protocol! No more closed protocol to reverse-engineer.
Unfortunately, logging into their service is a bit more complex than just providing a login and password: they support only OAUTH2-like authentication. The good thing is that gnome-online-accounts already supports oauth2 for Facebook and Google services, and I’ve seen while googling that the mechanism is pretty much the same as Facebook. So I’ve downloaded Microsoft’s documentation (registration required to get it), created my own Windows Live application, copied GOA’s Facebook code to start with, and replaced the bits according to MS’ doc and got the login page!
Unfortunately, from there it was failing to get the access-token, turns out the documentation contradicts itself. In one place they describe the exact same mechanism as existing code for Facebook, and the other places have small differences… I’ll let you guess which way actually worked 😉
Then I had to write in empathy-auth-client (an app usually used to ask user the password) code to instead take the access-token from GOA’s DBus API and give it to telepathy-gabble (our XMPP backend). After fixing a few bugs in telepathy-glib, telepathy-gabble and wocky, EUREKA! Got my MSN account connected in Empathy! Unfortunately it seems the features exposed by their XMPP server are really limited, just like Facebook’s XMPP.
At the same time, I’ve also added support in Empathy to connect to Facebook GOA accounts, and authenticate them using goa’s access-token instead of having to repeat the password.
Code source is available in bugzilla, waiting for review:
Still, we have an important issue:
This new auth mechanism require us to register a Facebook/Windows Live application. An application consists of a public ID and a secret key. Since gnome-online-accounts is open source code, it means the app’s secret key would be readable from its source code (atm it is given as configure flag), meaning that anyone could make its own malware claiming being the “GNOME” application. This could be considered by Facebook/Microsoft a violation of their service (if I understood correctly). For Google service, it is not a problem because they offer an “anonymous” application and it is user’s choice to accept to grant permission or not (again, if I understood correctly).
Thanks to Collabora for letting me working on this!
Awesome!
Fancy filling in the rest of the GOA account so that Evolution can access the Hotmail mail automatically as well? 🙂
What does evolution needs? Does hotmail support imap/pop nowadays anyway?
The secret API key problem is an interesting one, which also affects pitivi (for the ability to upload to Vimeo for example). I’m curious to see what solution you might come up with.
Hotmail supports POP3 for one year or two (not yet IMAP). So Evo would just need the username, password and server names: pop3.live.com and smtp.live.com
@Milan: The point here is that we don’t have username/password anymore. The authentication is made via a web page and it returns an access-token. I don’t know if MS’ pop3 support auth via that token. The email address is already available through GOA’s DBus API with my patches, so probably you just need to write the evolution bits. Dunno how it works for gmail.
xclaesse: Ah, I see. Evolution could probably identify the e-mail address as being a Hotmail one, and set the servers and username automatically. Users can type the password twice if needed.
BTW, what’s the advantage of using their XMPP API if that requires a secret key we cannot legally ship? Wouldn’t it be easier to use the MSN Messenger protocol, since Empathy supports it for a long time?
@Milan: The idea is to not have to re-type the password in each app. This systems makes possible to authenticate to the service onces then open as many connections as we want.
The advantage of XMPP is to promote open protocols. MSNP have a long history of incompatible changes, and developers had to reverse-engineer it again and again. I think here Microsoft made a real step toward openness and we have to encourage them that way.
xclaesse: Ideally, yes, it would be nice to encourage them. But ATM their XMPP service is even more closed than MSN Messenger because of that secret key. Until they change that, we can only use the old approach.
Anyway, gnome-keyring is designed to allow sharing a password between several apps. You could just call it “password for xyzaccount@live.com“, and applications can retrieve and use it for mail, chat or documents. Several authentications would happen, but stay hidden from the user.
I think that generating the secret key should be the responsibility of linux distros…
This is not the problem, whoever generate the key, it’s still supposed to be kept secret. Which is impossible in a open source software.
The “secret” key is a joke, anyone can extract it from a (non-web) application whether it is open source or not. Gnome should hard-code as the default and forget about it, nothing bad will come of it.
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
Hey there! Great to see your work on this.
I’d just like (as someone who’s been in the oAuth community for a long time) to clarify the misconception about consumer token/secret pairs. I’m not sure how MSN has implemented it, and it may be that their implementation is ungood, but it was *never* intended for *any* desktop application to use a consumer token/secret. The issues you put aside, in any desktop application the consumer secret would be trivial for any user to get access to, thus eliminating any security gained from being able to identify the client.
It is strongly recommended that any oAuth supporting site that wishes to support desktop apps, mobile apps, browser extensions, etc, allow for logins using a *blank* consumer token/secret pair and display to the user something like “Some application” instead of “Application named X”
This is my understanding too, google oauth has “anonymous” client id for that. Now I’ve been told that MSN has something like that too, but did not found yet 🙂
xmpp’s MS is very minimal then why MS says everyone can make um programs compatibles with MSN if the coolests features their xmpp don’t have?… so is it useless?