On replacing Basic Auth with OAuth 2.0

Dear OpenStreetMap Foundation,

I would like to express my concerns regarding OSM dropping support for Basic Auth (not to be confused with OAuth 1.0). The current intention is to replace it with just OAuth 2.0, which seems like the wrong tool for the job, as it will introduce unnecessary complexity, especially for new developers and people running basic edit scripts. This will most likely affect how many developers contribute to OSM in the future.

I initially expressed my opinion and suggested an alternative here, but I haven’t received a satisfying response/justification from the people responsible for the deprecation.

The Problem

Today, to start scripting on OpenStreetMap, all a person needs is their username and password. Then, they can simply call the API interface to perform any interactions. This system, while not secure (people tend to leave their passwords in plain-text files), makes it super easy to get started with OSM.

The procedure looks as follows:

  1. Save the username + password somewhere safe
  2. Attach the HTTP header: Authorization: basic

The current proposition is to replace this Basic Auth method with OAuth 2.0. Meaning that the new scripting procedure will look like:

  1. Register an OAuth 2.0 application (https://www.openstreetmap.org/oauth2/applications/new)
  2. Save the Client ID + Client Secret somewhere safe
  3. Generate an access_token with the use of a library or an external application
  4. Save the access_token somewhere safe
  5. Attach the HTTP header: Authorization: bearer

I believe this will significantly increase the barrier to entry for new and inexperienced developers. I believe the OpenStreetMap platform should strive towards being open and inviting to everyone. It will also make many applications more dependent on external libraries/applications potentially leading to supply chain attacks.

One More Hidden Problem

There is one more hidden problem with using OAuth 2.0 in scripts. Currently, access_tokens produced by the OSM server are never-expiring. This is quite a non-standard configuration, and ideally, we should switch to using a refresh_token + access_token pair in the future. While this is a non-issue today, if we proceed with the current Basic Auth → OAuth 2.0 replacement, tomorrow it will be a massive headache for all script developers. The scripting procedure will then look like:

  1. Register an OAuth 2.0 application (https://www.openstreetmap.org/oauth2/applications/new)
  2. Save the Client ID + Client Secret somewhere safe
  3. Generate a refresh_token with the use of library or an external application (long validity: months)
  4. Save the refresh_token somewhere safe
  5. Generate an access_token with the use of library (short validity: minutes)
  6. Save the access_token somewhere safe
  7. Attach the HTTP header: Authorization: bearer

The Simple Solution

Many public APIs have already solved this problem, and I believe it’s best to learn from them rather than coming up with our own clunky solutions.

I propose that we replace Basic Auth with the Personal Access Token (PAT) system. This will provide a secure, flexible, and simple solution for the basic auth security problem. It will require very little code/maintenance as it can be run on the existing OAuth 2.0 solution internally.

The PAT scripting procedure will look like:

  1. Retrieve the PAT token from OSM user settings
  2. Save the access_token somewhere safe
  3. Attach the HTTP header: Authorization: bearer

Basically, all the steps, from registering an OAuth application to generating tokens, are done server-side, hidden from the user. It has all the same benefits of OAuth 2.0 but none of the downsides of using it in a simple script application. The PAT system is very easy to use, secure, and provides no additional barrier to entry for new developers (it is also dependency-free!). This also future-proofs the potential refresh_token support as PATs will remain unaffected.

Regards,
Kamil

55 posts - 13 participants

Read full topic


Ce sujet de discussion accompagne la publication sur https://community.openstreetmap.org/t/on-replacing-basic-auth-with-oauth-2-0/108288