Move OSM authentication to OAuth 2.0

[pnorman]

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

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[mmd-osm]

I think you're using OrganicMapsTestUser for your Unit tests on master.apis.dev.openstreetmap.org. Are you using Basic Authentication or OAuth 1.0a there?

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.
Our goal is to avoid any disruptive and unexpected changes 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.

[biodranik]

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?

[mmd-osm]

The same OAuth1.0a as in production is used in debugging/CI on the dev server.

Thank you for your quick reply. I will discuss this point with our sysadmins, to make sure that we're not breaking anything here.

Do you have any recommendations or examples on how to properly migrate the manual auth code?

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.

• https://josm.openstreetmap.de/ticket/22810
• Use OAuth 2.0 westnordost/osmapi#33
• https://github.com/westnordost/osmapi/pull/35/files

[westnordost]

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 Authorization: Bearer <the OAuth2 access token> in the header of each HTTPS request. For getting the authorization token, the flow is similar but not exactly the same as for OAuth 1.0a.

[biodranik]

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.

[westnordost]

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.

[westnordost]

(I edited my post significantly to include more information)

[rtsisyk]

This issue is getting more important because of #7000

[rtsisyk]

Probably it will be easier to implement auth in Java and Swift separately instead of doing this business in C++.