id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
24932	[PATCH] Remove token leaves the OAuth access token in the preferences	wangi	team	"""Remove token"" leaves the OAuth access token in the preferences.

==== What steps will reproduce the problem?
1. Preferences > Connection Settings > Authentication: authorize with OAuth 2, so that JOSM has an access token.
2. Press ""Remove token"" and close the preferences.
3. Look at `preferences.xml` (or Advanced Preferences, searching for `oauth.access-token`).

==== What is the expected result?
The access token is gone from the preferences, as the authentication panel says.

==== What happens instead?
The authentication panel shows that there is no token, but the token is still stored in clear text under `oauth.access-token.object.OAuth20.<host>`. Only the parameters stored alongside it, under `oauth.access-token.parameters.OAuth20.<host>`, have been removed.

==== Please provide any additional information below. Attach a screenshot if possible.
`JosmPreferencesCredentialAgent.storeOAuthAccessToken(host, null)` builds both keys it deletes with the same prefix:

{{{#!java
final String hostKey = ""oauth.access-token.parameters."" + oauthType + ""."" + host;
final String parametersKey = ""oauth.access-token.parameters."" + oauthType + ""."" + host;
}}}

The first one should be `oauth.access-token.object.`, which is what the store and lookup branches of the same class use. JOSM still believes the token is gone because `lookupOAuthAccessToken()` needs both keys to be present, and the parameters were deleted.

The attached patch (against r19636) fixes the prefix. `CredentialsAgentTest.testLookupAndStoreOAuthTokens()` only checks that a lookup fails after removal, which is why this was not noticed; a new test in `JosmPreferencesCredentialAgentTest` checks that both keys are gone from the preferences and from the sensitive key list. It fails without the patch and passes with it. All tests in `org.openstreetmap.josm.io.auth`, `org.openstreetmap.josm.data.oauth`, `org.openstreetmap.josm.gui.oauth`, `org.openstreetmap.josm.gui.preferences.server` and `UserIdentityManagerTest` pass, and checkstyle is clean.

Tokens that were ""removed"" before this fix are still in the preferences of the users concerned. The patch does not clean those up: nothing can tell an orphaned token from one whose parameters were lost some other way, and authorizing again overwrites it anyway.

Found while looking at #24928."	defect	new	normal		Core			oauth token preferences security