Deprecation of HTTP Basic Auth and OAuth 1.0a

[opk12]

Thank you for this app. Just a heads-up if you didn't know, that OSM is slowly deprecating HTTP Basic Auth and OAuth 1.0a in favor of OAuth 2 (see announcement and tracking issue).

Related: #104

[Krakonos]

Thanks for the notice. I'm looking into this with a higher priority. There is OAuth2 library in Qt. However, reading osm docs it appears I need to generate client_id and secret. However, I can't keep the secret secret.

I looked briefly into josm and could not find a secret in the source code, not sure if they just inject it at buildtime though.

Do you have any visibility into the preferred way to do it?

[opk12]

Ah, this was briefly discussed today in the IRC chat #osm-dev (OFTC webchat, Matrix) and BTW there's also #josm if you ever need (OFTC, Matrix).

OAuth 2: How to best deal with the secret from step 1 at wiki.osm.org/wiki/OAuth in an open source app? If it's published to the GitHub repo, it won't be a secret anymore?

In that case you should mark the app as non-confidential when you register it Best practice is also to use PKCE when authorising see https://www.oauth.com/oauth2-servers/pkce/

I'm going to add a brief mention in that wiki article; feel free to link other OSM docs where you think it should be mentioned.

[Krakonos]

Thanks, that's helpful. I got it working. However, I'm not sure how to check if it's doing what it's supposed to do.

1. The code seems to work without the secret entirely.
2. When removing code_challenge and code_verifier, nothing really breaks.

I would expect the OSM server should require at least one of these things to be present?

Anyway, it looks like I can successfully use the OAuth2 flow with OSM API, so I'll integrate it with the rest of the system. The only big downside I see now is I seem to require a separate client id for every server (main/test api/3rd party servers).

[tsmock]

1. It should, assuming that PKCE is used. Technically, I don't think you need to use PKCE with OAuth 2.0, but you should. It is highly likely to be a mandatory part of the OAuth 2.1 specification (it is part of the current draft).
2. I would keep both code_challenge and code_verifier if you are using PKCE -- if removing them doesn't currently break something, then it is entirely possible that this is a bug in doorkeeper (the OAuth 2 library the OSM website is using) that will be fixed at some point. Or they aren't enforcing some of the recommended security practices yet.

When I was adding support for OAuth 2 in JOSM, I implemented a bunch of "optional" stuff that is likely to become mandatory with OAuth 2.1 and didn't implement some things that were optional in OAuth 2.0 but were removed/deprecated in the OAuth 2.1 draft.

If you are writing your own OAuth lib instead of using someone else's, I would highly recommend implementing PKCE. But you should probably use someone else's OAuth library.

I don't know how you are intending to implement the OAuth redirect, but in JOSM I'm using the remote control endpoint /oauth_authorization.

The only big downside I see now is I seem to require a separate client id for every server

Yep. That is a downside. I'm currently only planning on hardcoding the main api and test api oauth client ids in JOSM. There is an RFC for dynamic client registration, but it isn't currently implemented in the library the OSM website is using. ~~There is also an RFC for getting OAuth endpoints, which also isn't implemented in the library that the OSM website is using.~~

EDIT: The OSM website now implements the RFC for getting OAuth endpoints, see https://www.openstreetmap.org/.well-known/oauth-authorization-server .