OpenStreetMap OAuth2 support

[taylor.smock]

As a heads up, it looks like OSM may be implementing OAuth2 support soon. They will be using a different endpoint (/oauth2 is what it looks like).

See ​https://github.com/openstreetmap/openstreetmap-website/pull/3177 .

It looks like they will want to drop OAuth1 at some point.

[mmd]

Quoting a message Grant posted the other day:

OpenStreetMap.org will soon be able to do OAuth2, we plan on using OAuth2 for single-signon to OSM services, which might including: forum (or replacement), wiki, etc. If you have a view on OAuth2 implementation please get involved in the PR process: ​https://github.com/openstreetmap/openstreetmap-website/pull/3177

So now would be a good time for any JOSM specific requirements. Also, an OAuth2 instance is already up and running for testing: ​https://oauth2.apis.dev.openstreetmap.org/

[simon04]

One available Java library: ​https://github.com/scribejava/scribejava (supporting OAuth 1.0 as well as OAuth 2.0)

[mmd]

Just a quick heads up: On ​https://oauth2.apis.dev.openstreetmap.org/ CGImap has already been deployed to handle "Authorization: Bearer <token>" API calls using OAuth2 tokens.

As the exact timelines for deployment to production are not yet defined, there might be a situation when the Rails port API endpoints already support OAuth2 tokens, while the CGImap endpoints lag behind a bit.

In case you're planning to release OAuth2 support in JOSM in the near future, keep an eye on both issues:

​https://github.com/zerebubuth/openstreetmap-cgimap/issues/238
​https://github.com/openstreetmap/openstreetmap-website/pull/3177

[simon04]

Currently we use Signpost which is OAuth 1.0 only.

Patch to replace Signpost library with ScribeJava – ​https://github.com/openstreetmap/josm/compare/master...simon04:scribejava

ScribeJava – ​https://github.com/scribejava/scribejava – MIT license

Comparison of library sizes:

• ​https://repo1.maven.org/maven2/oauth/signpost/signpost-core/2.0.0/ – 47823 bytes
• ​https://repo1.maven.org/maven2/com/github/scribejava/scribejava-core/8.3.1/ – 136513 bytes

[sebastic]

The josm Debian package uses the liboauth-signpost-java package currently, ScribeJava is not packaged.

The ScribeJava dependencies may be problematic when using josm-sources.jar, because it lacks the sources of transitive dependencies (e.g. org.jetbrains.annotations for ch.poole.openinghoursparser).

com.github.scribejava.scribejava-core depends on com.github.scribejava.scribejava-java8 (required), commons-codec.commons-codec (optional), jakarta.xml.bind.jakarta.xml.bind-api (optional), and jakarta.xml.bind.jaxb-api (optional).

If the optional bits are not required for its use in JOSM, the impact on the Debian package is likely small.

[mmd]

Quick update: OAuth2 support moved to production earlier today

[skyper]

Is the non-working full OAuth1 authorization a product of this switch to OAuth2, see #21065?

[mmd]

Is the non-working full OAuth1 authorization a product of this switch to OAuth2, see #21065?

No, it's related to a bug fix for ​​https://github.com/openstreetmap/openstreetmap-website/issues/3241

[mmd]

For OAuth 2.0, we have explicitly whitelisted ​http://127.0.0.1:... as redirect URL endpoint (simiilar to JOSM remote control). Hopefully, this simplifies the implementation on JOSM side a bit.

[Don-vip]

Replying to sebastic:

The ScribeJava dependencies may be problematic when using josm-sources.jar, because it lacks the sources of transitive dependencies (e.g. org.jetbrains.annotations for ch.poole.openinghoursparser).

Created #21140 to address this separate issue.

[Don-vip]

Unit test to adapt during the migration to avoid random network failures:

 Test: testCookieHandlingCookieManager() took 12 sec(s) FAILED: java.net.UnknownHostException: www.openstreetmap.org
org.openstreetmap.josm.gui.oauth.OsmOAuthAuthorizationException: java.net.UnknownHostException: www.openstreetmap.org
	at org.openstreetmap.josm.gui.oauth.OsmOAuthAuthorizationClient.fetchOsmWebsiteSessionId(OsmOAuthAuthorizationClient.java:261)
	at org.openstreetmap.josm.gui.oauth.OsmOAuthAuthorizationClientTest.testCookieHandlingCookieManager(OsmOAuthAuthorizationClientTest.java:114)
Caused by: java.net.UnknownHostException: www.openstreetmap.org
	at java.base/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:220)
	at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
	at java.base/java.net.Socket.connect(Socket.java:609)
	at org.openstreetmap.josm.tools.Http1Client.performConnection(Http1Client.java:78)
	at org.openstreetmap.josm.tools.HttpClient.connect(HttpClient.java:148)
	at org.openstreetmap.josm.tools.HttpClient.connect(HttpClient.java:124)
	at org.openstreetmap.josm.gui.oauth.OsmOAuthAuthorizationClient.fetchOsmWebsiteSessionId(OsmOAuthAuthorizationClient.java:253)
	... 1 more

[Don-vip]

Milestone renamed

[Don-vip]

Milestone renamed

[stoecker]

Milestone renamed

[stoecker]

Milestone renamed

[taylor.smock]

Somewhat stupid question:
Do we have to use an external library for OAuth 2?

The actual implementation is simple (there is one in the Mapillary plugin), it is hooking up the UI that is kind of a PITA and keeping backward compatibility with OAuth 1.0a for awhile.

I also don't think we want to have a fully-automatic authorization flow for OAuth 2.0 -- opening a web page and then redirecting to a remote control endpoint should "just work".

I'll go ahead and upload what I currently have for OAuth 2, with a caveat that it isn't perfect (I need to figure out why it keeps asking for authorization to download data when in a non-authorized state).

Notes on the patch:

• OAuth 2.0 compliant (tested against OSM)
• OAuth 2.1 (draft) compliant (OSM supports PKCE, we are using response_type=code instead of response_type=token, and we don't pass the bearer token in URLs).
• OSM does not appear to give out refresh tokens, but code is present to handle refresh tokens in the patch.
• ​Doorkeeper (the library OSM is using for OAuth 2) does not support RFC 8414, so we have to hardcode the OAuth 2.0 URLs.

[stoecker]

Replying to taylor.smock:

Somewhat stupid question:
Do we have to use an external library for OAuth 2?

No. I usually try to implement protocols without libraries. E.G. I recently implemented MQTT and was much faster and reliable with my own stuff compared to using prepared libraries.

[taylor.smock]

Replying to stoecker:

No. I usually try to implement protocols without libraries. E.G. I recently implemented MQTT and was much faster and reliable with my own stuff compared to using prepared libraries.

Fair enough. I figured I'd ask since the code would be security sensitive, and I usually try to assume I'll mess something up (which is one of the arguments for using an external library -- hopefully someone would notice the problem).

TBH, it would be a lot easier to tear out all the current OAuth code than keep it, but I think we should keep the current OAuth code for now. I don't think users would appreciate being logged out.

My current action plan:

• Get patch to a state where it is generally usable. Ask someone for review. Apply patch in the next cycle (I don't want to apply it near release -- it is already kind of big, mostly due to UI stuff and adapting the OAuth 1.0 code).
• patch application: Make OAuth 2 available to Expert Mode users
• 3 months post patch: If no bug reports have occurred, make OAuth 2 available to all users
• 6 months post patch: Make OAuth 2 the default for new authentication
• 2+ years post patch: Remove OAuth 1 (and also remove OAuth 1 preferences?). But if OSM drops OAuth 1.0, remove it earlier.

[stoecker]

Replying to taylor.smock:

Fair enough. I figured I'd ask since the code would be security sensitive, and I usually try to assume I'll mess something up (which is one of the arguments for using an external library -- hopefully someone would notice the problem).

As we're the client side you only need to verify that you don't send out any data which shouldn't be sent out. The server side must ensure it's secure :-)

[stoecker]

Importance of this increased a bit. Maxar thinks about switching to an OAuth2 based solution.

[taylor.smock]

OK. I can apply what I have today -- it works, and I have written tests for a good chunk of the new code.

I'd still like someone else to look at it, just due to the size.

[stoecker]

I had a short look. Not really reviewing, but only looking for something obvious.

Are there hardcoded ID's in OAuth2?

clientId = "jo32l-hRbwWni_lnwQxffvSEfW-5agfuzoT8A33IFkY";
clientSecret = "OGH6-yYZHYAbw2J_LFS1yu1QiVFrCONhYWisftr6LRs";

The fixme looks wrong:

return Config.getPref().get("osm-server.auth-method", "oauth20"); fixme switch to oauth20 by default

[taylor.smock]

Replying to stoecker:

Are there hardcoded ID's in OAuth2?

We do (minimally) need the clientId. After I got done implementing OAuth 2 support, it turned out we don't need the clientSecret to be present at all. Speaking of which, can you generate a clientId from the ​JOSM account?

The fixme looks wrong:

I had that fixed already in my local copy. I think I had that set to see what OAuth 2 by default would do -- there were some bugs I squashed related to that.

I'll try to upload an updated patch as soon as possible (probably ~80 minutes from now).

[stoecker]

Replying to taylor.smock:

Replying to stoecker:

Are there hardcoded ID's in OAuth2?

We do (minimally) need the clientId. After I got done implementing OAuth 2 support, it turned out we don't need the clientSecret to be present at all. Speaking of which, can you generate a clientId from the ​JOSM account?

Please explain. Isn't that something which each user needs to do (i.e. The Fully automatic...).

[taylor.smock]

No. The clientId identifies the application. It is something we have to provide. There is a specification whereby we could do dynamic client registration (​RFC 7591, which we could get from ​RFC 8414), but the OSM server does not implement either of those RFCs. They use doorkeeper, which has an issue open for ​RFC 8414, but not for RFC 7591.

The basic workflow for an OAuth 2 request is as follows:

$ firefox 'https://www.openstreetmap.org/oauth2/authorize?response_type=code&client_id=jo32l-hRbwWni_lnwQxffvSEfW-5agfuzoT8A33IFkY&redirect_uri=http://127.0.0.1:8111/oauth_authorization&scope=read_gpx%20write_gpx%20read_prefs%20write_prefs%20write_api%20write_notes&state=be9874a9-51b1-41d4-b6ad-f3427dd1127d&code_challenge_method=S256&code_challenge=<challenge>'
# In the web browser, log in to OSM if not already
# Web browser then redirects to something like http://127.0.0.1:8111/oauth_authorization?code=<code>&state=be9874a9-51b1-41d4-b6ad-f3427dd1127d
$ curl 'https://www.openstreetmap.org/oauth2/token' -X POST --data-urlencode "grant_type=authorization_code&client_id=jo32l-hRbwWni_lnwQxffvSEfW-5agfuzoT8A33IFkY&redirect_uri=http://127.0.0.1:8111/oauth_authorization&code=<code>&code_verifier=<code_verifier>'
# This returns the actual token for the user

So we need to have the clientId somewhere in the application. We could try reusing the code we have for api keys, if you want to do that.

[stoecker]

Replying to taylor.smock:

No. The clientId identifies the application. It is something we have to provide.

Yes. That's clear. But for OAuth1 this is individual for the account. Your create and new setting/application and get the IDs. I don't see that's different for OAuth2. The user creates the application. The "Fully automatic procedure" calls the webpage with user login and clicks the relevant pages and reads the resulting data. The manual method lets the user do this and enter the data manually.

So we need to have the clientId somewhere in the application. We could try reusing the code we have for api keys, if you want to do that.

I still think that ID is a configuration option individual for each user.

[taylor.smock]

The terminology between OAuth 1.0a and OAuth 2.0 doesn't quite line up with what people expect.

We do have hardcoded keys for OAuth 1.0 (see source:trunk/src/org/openstreetmap/josm/data/oauth/OAuthParameters.java​).

The OAuth 1.0 consumer key is roughly equivalent to the OAuth 2.0 client id.

Definitions from the OAuth 1.0a spec:

Consumer Key: A value used by the Consumer to identify itself to the Service Provider.
Consumer Secret: A secret used by the Consumer to establish ownership of the Consumer Key.

Definitions from the OAuth 2.0 spec:

Client Identifier: The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client. The client identifier is not a secret;[...]

[stoecker]

Ok. For Oauth2 the ID would be - "edPII614Lm0_0zEpc_QzEltA9BUll93-Y-ugRQUoHMI".

For OAuth1: Is this actually ever used? Or only some legacy error stuff?

[taylor.smock]

Replying to stoecker:

For OAuth1: Is this actually ever used? Or only some legacy error stuff?

I'm not quite certain what you are asking here. I'm going to try to answer all the possible questions that you might have been asking.

1. Can people still use OAuth 1.0a?
   • Yes. I tried very hard to make certain that people wouldn't suddenly have to reauthenticate.
2. Are the OAuth 1.0 consumer key/secrets actually used?
   • Yes. The OAuth 1.0a consumer key/secrets are used in the fully automatic OAuth 1.0 workflow.
3. Do people actually use OAuth 1.0a?
   • I know at least one person uses it. And larger organizations should definitely be using OAuth (it avoids issues with OSM API rate limiting).

[taylor.smock]

Can you set the redirect URI for the application to http://127.0.0.1:8111/oauth_authorization? Or tell me what you set it to, so I can update the code?

[stoecker]

It's so long ago that OAUth1 was setup that I don't understand anymore how that works. Why does anything I do setup on the josmeditor account has any effect on other accounts? Are the "OAuth1 Client applications" and "OAuth2 applications" a global configuration which can affect all users? I.E. Can 1 user define an application and everybody use it?

P.S. I changed the redirect URL.

[taylor.smock]

Yes, a single user can create a client for others to use. Each user still has to authorize that client. This is why the code opens a browser window with a redirect_uri parameter. The redirect_uri parameter is then used to send the application the information for the next part of the OAuth 2 dance. Most applications actually register a system-level URI handler (in this case, we could redirect to josm://oauth_authorization?code=<code>&state=<state>, but I wasn't able to figure out how to register a URI handler system-wide in a platform-independent way with Java).

So, technically speaking, we could have just used the client id I generated (jo32l-hRbwWni_lnwQxffvSEfW-5agfuzoT8A33IFkY), but I felt that it would be a better long term to have all the hard-coded application ids be generated by the same account.

We can revisit the hardcoded client id if the OSM server ever supports dynamic client creation.

[stoecker]

How is the implementation of the version switch? My suggestion would be:

• When auth data is in the config use that
• When not use OAuth2 mechanism by default.

That way we get feedback for OAuth2, but majority of accounts will still work with existing config.

[taylor.smock]

That is technically very easy. It would be a oneline change to switch it to OAuth 2 by default (see the fixme you commented on in comment:35). I'll check and make certain that changing the default doesn't force everyone onto OAuth 2 though. If that happens, adding something that checks for an oauth 1 token should be doable.

How about we have an initial commit where OAuth 2 is not the default, I ask on various channels for feedback on it, and then change it to OAuth 2 by default next week?

I haven't noticed any bugs in my manual testing, but if I've learned anything, it is that other people tend to find problems I don't.

I've got a patch for the native password manager plugin as well, but I don't recall having tested it.

[stoecker]

P.S. Keep in mind that OAuth2 for imagery will need own IDs. The Client identifier probably is again an {apikey} type of value, even if handled somewhat special (i.e. not as part of the URL). The user specific data must be stored somehow as well. The OAuth classes need to cope with different sets of credits in different parts of the software.

How about we have an initial commit where OAuth 2 is not the default, I ask on various channels for feedback on it, and then change it to OAuth 2 by default next week?

You can, but you also skip that step and simply ask for tests. That's why we have a latest and tested :-)

[taylor.smock]

Replying to stoecker:

P.S. Keep in mind that OAuth2 for imagery will need own IDs. The Client identifier probably is again an {apikey} type of value, even if handled somewhat special (i.e. not as part of the URL). The user specific data must be stored somehow as well. The OAuth classes need to cope with different sets of credits in different parts of the software.

I'm pretty certain that the code I wrote handles all of that -- it stores OAuth parameters in oauth.access-token.parameters.<OAuth type>.<host> and the user information in oauth.access-token.object.<OAuth type>.<host>. I tried to not make it specific to one API/endpoint.

How about we have an initial commit where OAuth 2 is not the default, I ask on various channels for feedback on it, and then change it to OAuth 2 by default next week?

You can, but you also skip that step and simply ask for tests. That's why we have a latest and tested :-)

I haven't had the greatest experience with having people report bugs under latest. There have been a few times where I applied something 3 weeks prior to a tested release, and then I get bug reports after the tested release.

But I don't mind pulling the trigger all at once, I just want to avoid having to do a hotfix release.

[stoecker]

Usually no need for a hotfix for latest (only to reduce the amount of tickets when we did a major fail :-). Asking for tests by users in some forum still may help find bugs before the release. Usually the latest only finds bigger errors, as that are usually experienced users which wont use many functions normally (e.g. like the login procedure).

Generally I have no problem with breaking latest sometimes, so no need to be extremely cautious. Thought I prefer when we don't get swarmed with tickets. ;-)

[taylor.smock]

Replying to stoecker:

Importance of this increased a bit. Maxar thinks about switching to an OAuth2 based solution.

I don't know if Maxar has pinned down any type of implementation for their solution, but do you have any details you can share? There are a couple of ways I can see their solution going:

• They have a website set up that uses OAuth 2 to ensure the user is an OSM editor, and then it stores an API key in the user's OSM profile settings
  • We already have support for reading from OSM profile settings, so this wouldn't be a signficant issue. We'd just have to specially handle the imagery layers and redirect the user to Maxar's site to generate the API key. We might need to add an authenticate_url or something to the maps xml xsd.
• OSM editors need to make an account on Maxar's servers, which is then used for OAuth 2 in JOSM for signing the tile requests
  • This will be a bit trickier -- I'm going to hope they follow RFC 8414 so we don't have to significantly expand the maps xml xsd (4 additional fields, if I remember the necessary information correctly).

Also, even though this is a public bug tracker, can I mention that Maxar might be using OAuth 2 for imagery authentication when asking for feedback? I don't want to cause someone at Maxar to start panicking.

[stoecker]

Replying to taylor.smock:

Replying to stoecker:

Importance of this increased a bit. Maxar thinks about switching to an OAuth2 based solution.

I don't know if Maxar has pinned down any type of implementation for their solution, but do you have any details you can share? There are a couple of ways I can see their solution going:

• They have a website set up that uses OAuth 2 to ensure the user is an OSM editor, and then it stores an API key in the user's OSM profile settings
  • We already have support for reading from OSM profile settings, so this wouldn't be a signficant issue. We'd just have to specially handle the imagery layers and redirect the user to Maxar's site to generate the API key. We might need to add an authenticate_url or something to the maps xml xsd.
• OSM editors need to make an account on Maxar's servers, which is then used for OAuth 2 in JOSM for signing the tile requests
  • This will be a bit trickier -- I'm going to hope they follow RFC 8414 so we don't have to significantly expand the maps xml xsd (4 additional fields, if I remember the necessary information correctly).

Also, even though this is a public bug tracker, can I mention that Maxar might be using OAuth 2 for imagery authentication when asking for feedback? I don't want to cause someone at Maxar to start panicking.

ATM It's an idea. We'll see what evolves. But as far as I remember we already had another request once for something similar, so keeping this as option probably is not wasted even if Maxar will choose another path.

[taylor.smock]

In 18650/josm:

Fix #20768: Add OAuth 2.0 support

This also fixes #21607: authentication buttons are unavailable when credentials
are set.

[taylor.smock]

In 36049/osm:

Fix #20768: Add OAuth 2.0 support

This also fixes #21607: authentication buttons are unavailable when credentials
are set.

[taylor.smock]

In 36050/osm:

see #20768 (dist): Add OAuth 2.0 support

[taylor.smock]

In 18651/josm:

See #20768/r18650: Add OAuth 2.0 support

This fixes tests that don't have the HTTP factory set or have "​http://invalid"
set as the OSM API url.

It also fixes 2 static analysis warnings.

[stoecker]

What do you think: Add a startup notice to ask for tests?

[taylor.smock]

In a different context, I thought it might be a good idea to have an Upcoming Features section in the startup notes. At least for anything major.

I'll go ahead and update the startup notes in a bit.

[stoecker]

Replying to taylor.smock:

In a different context, I thought it might be a good idea to have an Upcoming Features section in the startup notes. At least for anything major.

I'll go ahead and update the startup notes in a bit.

In the past new features sometimes have been added before the release. The current method developed over the time. It's not set in stone. Simply add something when necessary.

[skyper]

Great, I just successfully uploaded my first CS with OAuth2.

Some small cliches:

• After the login on OSM and allowing JOSM, I am redirected. Could that redirect please open in a new tab as I loose the information that I am still logged in on the OSM server.
• Trying to remove the token in JOSM, I have to click on "Remove Token" for a second time to really remove it. The first time I get a dialog about the future setting for obtaining the token and only the second click finally removes the token.
• After removing the token from JOSM, the dialog for obtaining the token pops up periodically after some time. Guess it is every five minutes cause JOSM tries to look for new OSM mails. Even multiple identical dialogs are created if you wait long enough. Even removing the token from OSM server does not make a difference.
• I do not find an option to create an additional token. Is it not possible to have several tokens for JOSM with OAuth2?

I'll keep on testing.

[taylor.smock]

Replying to skyper:

Some small cliches:

• After the login on OSM and allowing JOSM, I am redirected. Could that redirect please open in a new tab as I loose the information that I am still logged in on the OSM server.

I'm assuming you are talking about the flow where

• JOSM opens a web page (on openstreetmap.org)
• User logs in/grants access
• OSM redirects to the remote control endpoint
• User sees "OK"

We might be able to redirect to the main OSM webpage, but I don't know if we get the information needed to redirect to the main site (we don't want to hardcode a redirect in for osm.org, I don't think).

• Trying to remove the token in JOSM, I have to click on "Remove Token" for a second time to really remove it. The first time I get a dialog about the future setting for obtaining the token and only the second click finally removes the token.

Thanks. I'll see if I can repro and fix.

• After removing the token from JOSM, the dialog for obtaining the token pops up periodically after some time. Guess it is every five minutes cause JOSM tries to look for new OSM mails. Even multiple identical dialogs are created if you wait long enough. Even removing the token from OSM server does not make a difference.

I'll see if I can repro and fix.

• I do not find an option to create an additional token. Is it not possible to have several tokens for JOSM with OAuth2?

Right now, now. We store the tokens in a preference key, and I don't think I implemented something for multiple users on the same endpoint.

Realistically, the way to handle multiple users would be to have a list of users to choose from, with whichever one is selected being the one in the "main" preference.

I'll keep on testing.

Thanks.

[taylor.smock]

In 36051/osm:

See #20768: OpenStreetMap OAuth2 support

The SdsCredentialAgent extends AbstractCredentialsAgent, which means it needed
to be updated.

The agent is used in one place, and does not call any of the new methods. As
such, the new methods will just throw an exception.

[taylor.smock]

In 18654/josm:

See #20768: OpenStreetMap OAuth2 support

This fixes an issue where the user would be prompted to log in immediately after
removing the OAuth token.

[taylor.smock]

@skyper: r18654 should fix both of the problems you encountered ("Remove Token" and "new OSM mails").

[skyper]

Replying to taylor.smock:

Replying to skyper:

Some small cliches:

• After the login on OSM and allowing JOSM, I am redirected. Could that redirect please open in a new tab as I loose the information that I am still logged in on the OSM server.

I'm assuming you are talking about the flow where

• JOSM opens a web page (on openstreetmap.org)
• User logs in/grants access
• OSM redirects to the remote control endpoint
• User sees "OK"

Yes, exactly.

We might be able to redirect to the main OSM webpage, but I don't know if we get the information needed to redirect to the main site (we don't want to hardcode a redirect in for osm.org, I don't think).

If possible it would be nice to stay on the OSM user page and have the "OK" as new tab.

[taylor.smock]

Replying to skyper:

If possible it would be nice to stay on the OSM user page and have the "OK" as new tab.

This is not possible on our end -- this is something that would have to be done on the OSM side. And I don't think they would want to do that (it might mess up expectations for the iD workflow).

Also, it looks like I might have to take back comment:65 partially. It looks like "new OSM mails" might not be fixed in all instances.

[taylor.smock]

In 18655/josm:

See #20768: OpenStreetMap OAuth2 support

This fixes an issue where the user would be prompted to log in after
removing the OAuth token since the message notifier thread was not stopped.

[skyper]

See #22744 for another problem.

EDIT: Again with a dialog to grant access popping up.

[taylor.smock]

See #22730 for another problem (Http1Client and Http2Client have differing default behaviors). It is easy enough to work around (we can explicitly set the Content-Type header).

EDIT: It looks like that affects OAuth 1 as well.

[taylor.smock]

In 18662/josm:

Fix #22744, see #20768: Fix NPE when switching to authentication methods

The NPE occurs because the UI state and the saved preferences state does not
match. This is solved by saving the state to preferences and then reloading it.

This also fixes an issue where the http2 plugin would prevent the OAuth
workflow from working, due to differing default behaviors (see #22730).

[taylor.smock]

In 18667/josm:

see #22744, #20768: Don't remove OAuth 1 token when authenticating with OAuth 2

There is a button for users to remove either token if the user wants to do so.

[anonymous]

Replying to taylor.smock:

There is a button for users to remove either token if the user wants to do so.

This button does not work.
If I use the "Remove token" button for OAuth 1.0a, the token is removed from the GUI, but after JOSM restart, the OAuth 1.0a token reappears.

JOSM version 18670.

[taylor.smock]

The button was added as part of the initial OAuth 2 support. I probably broke it with r18667. I'll see if I can come up with a test for it so it doesn't get broken again.

[taylor.smock]

In 18671/josm:

See #20768: Ensure that removing an OAuth 1.0 token actually removes the token

[taylor.smock]

Followup: #22810 (the operations working group is now looking at deprecating HTTP Basic Auth and OAuth 1.0a).

[stoecker]

Replying to taylor.smock:

Followup: #22810 (the operations working group is now looking at deprecating HTTP Basic Auth and OAuth 1.0a).

So make OAuth2 default now :-)