Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Add support for "login with Facebook" and MS live #153

Closed
wants to merge 4 commits into
from

Conversation

Projects
None yet
7 participants
Member

apmon commented Nov 2, 2012

Annoyingly Facebook and MS Live accounts do not implement OpenID which is the correct way to do authentication. Therefore they are not covered by the existing implementation of third party authentication. Imho they are, however, important enough to (reluctantly) warrant some special casing to support them and make it easier for new users to create an OpenStreetMap account.

This implementation uses the OAuth2 standard to retrieve user information from either Facebook or a Windows Live account that can then be used for authentication. It reuses a lot of the openID infrastructure to simplify the code and minimize the special casing.

As it uses OAuth2 and OAuth requires applications to register with the provider, the website needs to be
registered with Facebook and MS Live to use this feature. The oauth app id and app secret are stored
in application.yml

Contributor

pnorman commented Jul 20, 2013

@SIMONpool, is the status of facebook logins held at LWG?

@apmon, you have a dev instance that can be used for testing, right?

Contributor

simonpoole commented Jul 20, 2013

We need to ask Facebook (or rather their legal department) if they would be OK with us using it. Nominally we would not be adhering to their terms,

Member

apmon commented Jul 20, 2013

Yes, there is a test instance at http://apmon.dev.openstreetmap.org/ with up-to-date code

For some background on the legal issues for others reading this ticket:

Unlike Google and Yahoo, Facebook doesn't implement the appropriate APIs for federated authentication, which would be OpenID. Instead it (miss)uses OAuth for this purpose (as it presumably expects wanting to also retrieve the full social graph and other private information of a user from Facebook). With OAuth, however the "relying party" has to register with each "identity provider" explicitly. I.e. OSM(F) has to create an account with Facebook and register osm.org as an OAuth app. As such it has to explicitly sign the Terms of Use contract with facebook.

If I remember the issue correctly, the problem with the Terms of Use is the clause that the facebook app (in this case osm.org) has to be legal in any country it is used. However, mapping might not be legal in all countries, however osm.org (and as extension as a facebook app) is technically accessible in those countries. Now the worry is that facebook could sue OSMF for violating their TOU, due to this.

I can't remember if there were other issues raised.

This patch however also implements "login with Microsoft Account" (which is in the same technical boat of using OAuth and therefore needing an application ID by registering osm.org with Microsoft). Although Microsoft-Account might not be as "sexy", there are still over 500 million users with Microsoft accounts and it integrates nicely with Windows 8. So a big potential for use as single sign on solution. Has the LWG looked at the status of the TOU of Microsoft? Are there any issues with that? Can this part of the patch be deployed?

Contributor

pnorman commented Aug 27, 2013

@apmon do you have a link to the Microsoft TOU?

As a more general question, what happens to these users if Facebook/MS cut off the service, either because of legal concerns or technical reasons. Will the users still be able to log in to the OSM website somehow?

Member

apmon commented Aug 27, 2013

Yes, users will still be able to log in to the OSM website. The way "login with openID", "login with google" (which just uses plain OpenID, "login with facebook" and "login with Microsoft" are set up, it is simply an (additional) alternative to a password. Everything else is identical.

If users specify their own password in addition to using "login with FB/MS", they can simply use that to log-in, if for what ever reason the the service is cut off.

If users haven't specified a password during signup, the system generates a long random password in the background (that no one knows). They can then simply go through the standard password recovery mechanism to obtain a new password.

Member

apmon commented Aug 27, 2013

The page you need to register the website on for Microsoft is: https://account.live.com/developers/applications/index
This then links to the following terms of use: http://msdn.microsoft.com/en-US/library/live/ff765012

Member

apmon commented Sep 9, 2013

I have rebased my facebook-login branch to the latest code and checked that it still works.

Contributor

pnorman commented Sep 20, 2013

A quick skim of the Microsoft policy doesn't find anything with the issues of the FB one. The equivalent statement in the MS terms is "you must comply with all applicable laws and regulations", which is a meaningless statement, because as a matter of law you must comply with all applicable laws and regulations.

Most of the terms are concerned with either desktop applications or applications using features other than identification (e.g. apps sending messages through MSN Messenger).

This is a cursory review, but encouraging.

apmon added some commits Oct 13, 2012

Add login with facebook and MS live
Facebook and MS Live accounts don't implement OpenID, so aren't covered by the existing
implementation of third party authentication. However, imho they are important enough
to warrant some special casing to support them.

This implementation uses OAuth2 standard to retrieve user information from either Facebook or a Windows Live
account that can then be used for authentication. It reuses a lot of the openID infrastructure to simplify
the code and minimize the special casing.

As it uses OAuth2 and OAuth requires applications to register with the provider, the website needs to be
registered with Facebook and MS Live to use this feature. The oauth app id and app secret are stored
in application.yml
Change url_field to text_field to support "facebook urls"
In order to be able to reuse as much of the OpenID code, we
shoehorn the facebook and MS live identities into a custom "URL",
however this URL is deliberately non valid to not clash with any valid
urls. So we need to disable rails URL check

mourner commented Feb 28, 2014

Any updates on this?

Contributor

simonpoole commented Feb 28, 2014

@mourner the LWG gave a green light from the legal pov at its last meeting.

mourner commented Feb 28, 2014

Nice!

Contributor

pnorman commented Jun 6, 2014

To collect everything, link to minutes: https://docs.google.com/document/d/1uemhXWKwbu3RNjAWcG0R-nEFaN1FHjZl1McFwjXkNSc/pub

10. FB and MS Logins

Kai Krüger would like a minuted “OK” that he can proceed.
The LWG has no objection to adding Facebook and MS login support and considers the risk for legal issues minimal.

else
update_user(@user, params)
end
- elsif using_open_id?
+ elsif using_federated_login?
# The redirect from the OpenID provider reenters here
# again and we need to pass the parameters through to
# the open_id_authentication function
@pnorman

pnorman Oct 26, 2014

Contributor

open_id_authentication is no longer the name of the function, and it's not OpenID specific

@@ -265,7 +265,7 @@ def create
elsif @user.openid_url.present?
# Verify OpenID before moving on
@pnorman

pnorman Oct 26, 2014

Contributor

Not just OpenID

##
# handle OpenID authentication
def openid_authentication(openid_url)
+ #logger.debug "OpenID_authentication" + openid_url
@pnorman

pnorman Oct 26, 2014

Contributor

Should this be deleted or just commented?

@@ -80,6 +80,13 @@ defaults: &defaults
#oauth_key: ""
# OAuth consumer key for iD
#id_key: ""
+ #OAuth2 parameters for facebook login
@pnorman

pnorman Oct 26, 2014

Contributor

Should we document how to set this up and where to register with FB/live?

@@ -80,6 +80,13 @@ defaults: &defaults
#oauth_key: ""
# OAuth consumer key for iD
#id_key: ""
+ #OAuth2 parameters for facebook login
+ facebook_app_id:
@pnorman

pnorman Nov 7, 2014

Contributor

Other unset config items in the defaults (oauth consumer keys, etc) are commented out - should this be the same?

Contributor

pnorman commented Nov 7, 2014

Setup notes from @apmon

04:04 < apmon> pnormal: To register a new oauth app on facebook, go to https://developers.facebook.com/ and then choose the "app", "register new app" drop down
               menu item
04:16 < apmon> pnormal: For the MS live account, you can register the application at https://account.live.com/developers/applications/index
Contributor

ppawel commented Feb 12, 2015

What is the current status? @apmon Are you working on this? If not then I could possibly try to take a stab at rebasing and dealing with Google phasing out OpenID.

Contributor

pnorman commented Feb 12, 2015

I don't believe anyone is actively working on this.

Contributor

mvexel commented Feb 12, 2015

Vaguely related, is this an OSM web site bug?

Contributor

mvexel commented Feb 12, 2015

It looks like Google is retiring OpenID 2.0 support, moving everything to something called OpenID Connect which seems to be based on the OAuth 2.0 flow. More info here - is this something we're already supporting, or looking to support? (potentially related to #894)

Owner

tomhughes commented Feb 12, 2015

Oh for crying out loud, can we please stop this splattering comments across any bug vaguely related to your current personal bugbear.

The google issue is being dealt with in #897 not here...

Contributor

mvexel commented Feb 12, 2015

Thanks for pointing that out @tomhughes !

Owner

tomhughes commented May 20, 2015

Support for Facebook and Windows Live has now been added via #960 and is live.

Thanks for your work on this @apmon even if we didn't wind up using this version in the end, and apologies that it all took so long to get resolved.

@tomhughes tomhughes closed this May 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment