OpenStreetMap
The Operations Working Group is looking at what it take to deprecate HTTP Basic Auth and OAuth 1.0a in favour of OAuth 2.0 on the main API in order to improve security and reduce code maintenance.
Some of the libraries that the software powering the API relies on for OAuth 1.0a are unmaintained, there is currently a need to maintain two parallel OAuth interfaces, and HTTP Basic Auth requires bad password management practices. OAuth 2.0 libraries should be available for every major language.
We do not yet have a timeline for this, but do not expect to shut off either this year. Before action is taken, we will send out more notifications. Deprecation may be incremental, e.g., we may shut off creation of new applications as an earlier step.
What can you do to help?
If you are developing new software that interacts with the OSM API, use OAuth 2.0 from the start. Non-editing software can require authentication support, e.g. software that checks if you have an OSM login.
If you maintain existing software, then look into OAuth 2.0 libraries that can replace your OAuth 1.0a ones. We do not recommend implementing support for either protocol version “by hand”, as libraries are readily available and history has shown that implementing your own support is prone to errors.
If you do not develop software that interacts with the OSM API, this change will not directly impact you. You may need to update software you use at some point.
Discussion
Comment from eternaltyro on 19 June 2023 at 13:17
Hey Paul, is there a timeline for deprecation of 1.0?
Comment from mmd on 27 June 2023 at 20:16
My target timeline for the C++ part of the API is no later than Q1/2024, see https://github.com/zerebubuth/openstreetmap-cgimap/issues/286
I don’t know what OWG will eventually come up with. Also sysadmins have the final say on what to deploy at which point in time.
Comment from danieldegroot2 on 27 September 2023 at 10:44
This issue is being tracked at https://github.com/openstreetmap/operations/issues/867
Comment from TrickyFoxy on 17 December 2023 at 12:29
And although as a programmer, I understand the benefit of abandoning legacy, it’s still going to be a very painful change.
The StreetComplete beta was recently released. I was de-logged, I tried to log in, logging in via social networks is inconvenient, I had to look for a password….
And then there are users of Organic Maps, Maps.me, OsmAnd. I’m scared to imagine if they will remember their passwords and want to recover them.
In the case of Maps.me, I doubt that they will migrate to OAuth 2.0 at all. (but someone will probably breathe a sigh of relief).
Password login, while not secure, is many times easier for novice developers. No libraries, no getting tokens. Want to test the API in the sandbox? Change one URL. I’ve even as a mapper used this in JOSM. With OAuth you get confused with application tokens, but with password it’s simple.
Comment from Mateusz Konieczny on 12 January 2024 at 19:56
I must say that looking at https://github.com/metaodi/osmapi/issues/144 and https://github.com/metaodi/osmapi/blob/develop/examples/oauth2.py this looks really annoying and laborious in practice for someone using scripts :(
Comment from Mateusz Konieczny on 12 January 2024 at 21:13
https://github.com/openstreetmap/operations/issues/867#issuecomment-1889898618 mentions that it will stop various places to ask directly to passwords
Comment from Matija Nalis on 22 January 2024 at 00:04
More discussion about the issue on https://community.openstreetmap.org/t/on-replacing-basic-auth-with-oauth-2-0/108288
Comment from mmd on 23 January 2024 at 19:00
So yes, you can do all this in a few lines of shell script, by using only curl and jq, without any external libs, local HTTP server, or anything: https://gist.github.com/mmd-osm/b61956bb4b92e9b37488189379b380c9
Before trying this out, be sure to sign up on the dev instance https://master.apis.dev.openstreetmap.org (you already knew this).
Bonus points for storing the access token in a local file, so you don’t need to go through the osm.org authorization each time you’re running the script. I was too lazy to implement that.
If you’re also too lazy like me, you can also use the access token, and treat it as some kind of Personal Access Token. Line 14 shows you how to use the access token to call an API endpoint.
Disclaimer: This is only meant for personal scripts and local testing. Also, please register you own app and replace client id and client secret with your own values. Use urn:ietf:wg:oauth:2.0:oob as redirect URL.
Comment from pnorman on 23 January 2024 at 22:56
mmd’s example does this in 11 lines of bash, including endpoint discovery. I think the right environment variables could make all subsequent curl calls add that header, but you might need to write to a
.curlrcfile and change$CURL_HOME. Please don’t do this as if you aren’t careful you’ll leak the token everywhere. This is better than the HTTP Basic equivalent of leaking username/pass everywhere, but still best avoided.I haven’t had to implement an OAuth 2.0 CLI app before, so I wanted to see how long it would take me. It took me about half an hour using a library I had never used or read the documentation of. I could have used Ilya’s script which does all of this and handles saving the token.
I implemented what mmd did, except without endpoint discovery in 13 lines, taking under half an hour starting from scratch. The code and output from running it is https://gist.github.com/pnorman/19c103add9fcc6b9ee8a5792d2598ef4. I’ve deleted the OAuth 2 application, so you’ll need to make your own.
From this point in my code writing API calls by hand would just be like normal, as the interface is the same as the requests library.
If you’re doing this for real best practice would to have some error handling better than bailing out on error
Comment from Mateusz Konieczny on 24 January 2024 at 09:02
And to get client_id and client_secret - visit https://www.openstreetmap.org/oauth2/applications
Or https://master.apis.dev.openstreetmap.org/oauth2/applications - I guess, for test server