-
-
Notifications
You must be signed in to change notification settings - Fork 936
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move OSM authentication to OAuth 2.0 #6144
Comments
I think you're using I need to know if we have to take additional steps before merging the OAuth 1.0a removal in CGImap. Since we have an automated deployment in place, that would immediately break OAuth 1.0a for changeset uploads on the dev instance. Relevant commit is: zerebubuth/openstreetmap-cgimap#354 NB: Production is not impacted by any of this at this point in time. |
The same OAuth1.0a as in production is used in debugging/CI on the dev server. Do you have any recommendations or examples on how to properly migrate the manual auth code? |
Thank you for your quick reply. I will discuss this point with our sysadmins, to make sure that we're not breaking anything here.
My recommendation here would be very clear to reach out to both @tsmock (JOSM) and @westnordost (StreetComplete). They have either already completed the switch to OAuth 2.0, or are currently in the process of rolling out OAuth 2.0 as part of a beta version. I hope they're ok to mention them here, since I believe they could provide very valuable insights. Are you looking for solutions for both Java and C++? JOSM and StreetComplete should cover Java/Kotlin. @tsmock also had some discussions with Merkaartor, a C++ app. I'm not sure if this would be helpful in your case. You can of course also post to openstreetmap/operations#867, which is the central issue to manage the transition. Besides all admins/core maintainers I would expect that you could reach out to a larger group of app developers this way. Linking to a few relevant issues/PRs. |
Hey @biodranik , I summarized it here: MarcusWolschon/osmeditor4android#2401 (comment) Feel free to ask me questions, I very recently concerned myself with it so my knowledge of it is fresh. In a nutshell, using an OAuth2 access token is as simple as adding |
Thanks, @westnordost, that is helpful. The problem is that liboauthcpp used in OM does not support OAuth2: sirikata/liboauthcpp#24 Implementing the spec manually in C++ is not an easy task. If anyone is aware of simple and lightweight C++ implementations without networking code, please let us know. |
You don't need a library for passing the access token. For getting the access token, ... maybe, but it is really not a lot. I implemented the logic in ~120 source lines of code, so that's the order of magnitude of code you would like to have outsourced into a lib. (The links to the source code are contained in my previously linked comment.) For getting the access token, indeed to implement the whole spec would be quite a large undertaking, so an OAuth2 library that does that would not be lightweight. Also, note that to get the access token at the end, the result from the server must be parsed as a JSON. So, a library that does all that (120 source lines of code worth of logic) for you will very likely pull in another dependency to a JSON parsing library, i.e. maybe a different one that you are using for other stuff. Not to mention the dependency to actually do HTTP requests. Oh, and, and optional feature that is nevertheless supported by OSM and recommended to be used is to include a PKCE key exchange in the process, which means a library that implements that (I think it is pretty standard these days) also needs a dependency to some sha256 hasher. I am writing this because you mentioned that it should be lightweight. If you are looking for a library without networking code and without JSON parsing code, to be honest, there is not much code left. The exchange that happens to get the access token is basically nothing else than a bunch of HTTPS requests and reading the responses. |
(I edited my post significantly to include more information) |
This issue is getting more important because of #7000 |
Probably it will be easier to implement auth in Java and Swift separately instead of doing this business in C++. |
@rtsisyk as it was mentioned by @westnordost and @Zverik, the decision to use login and password was a deliberate one, forced by issues with using Webview or browser login. To clarify: the existing OAuth1.0a solution was using webview from the start. And it can be adopted to using external web browser if necessary without migrating to OAuth2. |
I didn't get the problem with WebView. OAuth2 is definitely better than asking the user to enter their password. |
As far as I know it is easy to circumvent this restriction by setting the user agent of the WebView to something other than the default. (You could test this by trying to login with OAuth with Google on OSM within STreetComplete.) But anyway, using the browser is probably the better idea anyway. Though, expect issue tickets to appear that complain about that the login doesn't work on their browser or maybe even the default browser of certain Android distributions such as LineageOS (last time I checked). Also, the information may be outdated, but back when I looked into the topic, the recommendation (or even obligation?) for apps on the Apple App store was the exact opposite, "to not break the native experience". But take my comment with a grain of salt, because this was quite some years ago. Browser support may have been fixed, Apple may have either changed their policies or I misremember it in the first place. |
Thanks for the hint! Apple is ok with the app login. It's a Google Play issue only. CC @rtsisyk |
This comment was marked as resolved.
This comment was marked as resolved.
the registration button takes you to the OSM site, you can't create an account in-app. |
...And the login is not automated, users are doing it manually. |
We are looking for Android engineers to implement new OSM authorization in the app. This work will be financially rewarded based on fair estimation of time and efforts spent. Please post your proposal in this thread. |
This is not a proposal, just a few comments after a quick look at the source code in order to help make clear the scope of it: The biggest part of the current OAuth 1.0a authentication is implemented in osm_oauth.cpp. The normal OAuth authorization flow (OAuth 1.0a and OAuth 2.0 are quite similar) would be to
OM is currently using the following curious approach to OAuth authorization instead. As far as I understand:
I believe it is done that way to avoid the user leaving the app's UI for authorization but certainly is somewhat of a misuse of OAuth. Could just as well use HTTP Basic Auth, then. However, this is akin to how JOSM did it in the past, as far as I know. Obviously, I strongly recommend just doing the normal OAuth 2.0 authorization flow, which is akin to the OAuth 1.0a but even a little simpler (actually). It is less code, it is more trustworthy and more future-proof (less chance that something breaks, when e.g. the HTML on osm.org changes). Google additionally requires (but it can be tricked) to use the browser instead of a WebView. Note that OAuth 2.0 requires some basic JSON parsing, as the access token response is in JSON. The Android part of the Login is in OsmLoginFragment.java and OsmOAuth.java, which is naturally almost empty because it does almost nothing else than provide the UI for entering the username+password and initiate the authorization in native code. This also means that to implement OAuth 2.0 authorization only for Android but not for iOS makes no sense, as the main part is implemented in native code. For further help on implementing OAuth 2.0, see MarcusWolschon/osmeditor4android#2401 (comment) , it also includes links to implementation. |
I am removing this ticket from Release Blockers because it is not a blocker and it is actually going into the subsequent release (after the current one). |
Is your feature request related to a problem? Please describe.
OAuth 1.0a is deprecated, and programs which use it to authenticate requests to OpenStreetMap should move to OAuth 2.0. A date has not yet been set for turning off OAuth 1.0a and HTTP Basic.
It's best to move to OAuth 2.0 well in advance of any turn-off, because users may take some time to upgrade software and to re-authenticate.
See openstreetmap/operations#867 for details.
Upvote & Fund
The text was updated successfully, but these errors were encountered: