[openstreetmap/openstreetmap-website] Add MAPS.ME authentication (#1433)

Ilya Zverev notifications at github.com
Thu Feb 9 15:58:41 UTC 2017

> Hmm I'm surprised we are considering facebook provided emails as verified as I don't believe they are verified in any real sense - like most sites they will probably have verified it when the user signed up but that might have been years ago.

The same is true for OSM emails. In #1096 we found evidence that Facebook only provides verified emails, but if we take into account that all addresses become obsolete with time, then we should not treat anything to be verified, and even maybe ask users to re-verify their email addresess once a year.

> Can you give a detailed explanation of the flow that uses [`mapsme_token` provider], and why it needs to be a separate provider rather than piggybacking on the other one?

The provider is included in `omniauth-mapsme` gem. After a successful authentication it replaces the `:provider` field with `mapsme`, imitating a sign-in with that provider. It is built after the [omniauth-facebook-access-token](https://github.com/SoapSeller/omniauth-facebook-access-token), which is also invisible to the target app.

Regular OAuth2 flow from the `mapsme` provider is:
1. User goes to `%osm%/auth/mapsme`
2. User is redirected to `https://passport.maps.me/oauth/authorize?...&state=399whatever99`
3. User authorized against maps.me server, if not yet
4. User is redirected back to `%osm%/auth/mapsme/callback?code=...&state=399whatever99`
5. Server sends a request to `passport.maps.me` with the given code and receives as access token
6. Server uses that token to query the provider for user id and email
7. User is redirected to a relevant page, or `%osm%/user/new`.

Now, if we already have an access token, we would want to skip steps 2-5 and simply give the server the token. It is not bound to an application, so you can make requests even from a different country using the same token. Alas, we have no way of giving the token in that workflow: it has only intermediate steps.

The workflow with a prepared token is:

1. User goes to `%osm%/auth/mapsme_token/callback?access_token=123whatever456`
2. Server uses that token to query the provider for user id and email
3. User is redirected to a relevant page, or `%osm%/user/new`.

In theory I could merge these two strategies into one, checking in `callback_phase` whether the `access_token` parameter is specified, but it would be harder than just to make two separate strategies.

With a mobile app, when signing in to OSM via a facebook, the following workflow would be used:

1. Sign in to Facebook or Google using a Native SDK and get an fb_access_token
2. Use fb_access_token to sign in to passport.maps.me using a series of API calls, and get an access_token
3. Open a WebView for `https://www.openstreetmap.org/auth/mapsme_token/callback?access_token=...` and wait for it to return osm_access_token and osm_access_secret.

This way a user won't have to type their password for anything, since WebView doesn't have cookies from a native sdk or from sessions in a web browsing app. And even if that was okay, Google will start [blocking OAuth requests](https://www.theregister.co.uk/2016/08/23/google_to_block_web_views_from_using_its_oauth/) in a WebView starting this April.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20170209/08829b6a/attachment-0001.html>

More information about the rails-dev mailing list