Keycloak oauth configuration code not cleared

problem

No response

versions

ACS 4.23 RC

The keycloak oauth was introduced with the pr
https://github.com/apache/cloudstack/pull/13033

The steps to reproduce the bug

Steps to reproduce the behaviour

1. Run a keycloack service using a docker container

docker run -d --name keycloak -p 8081:8080 \
    -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin \
    quay.io/keycloak/keycloak:latest start-dev

2. Login to the keycloak ui and create client

Example : create a client name cloudstack

• Valid redirect URIs: http://mgmtip:8080/*
• Web origins: http://mgmtip:8080

3. In CloudStack (Settings → OAuth Settings, registering the keycloak provider

• Redirect URI: http://mgmtip:8080/client/#/verifyOauth (must match the Keycloak client's registered value exactly)
• Authorize URL: http://keycloakip:8081/realms//protocol/openid-connect/auth
• Token URL: http://keycloakip:8081/realms//protocol/openid-connect/token

4. Create a matching CloudStack user (username == the Keycloak test user's email).

5. Try login with keycloak provider flow end to end > Login works fine

Issue to reproduce the bug

1. Cause one failure attempt with keycloak oauth attempt

Rename a CloudStack username so it no longer matches an OAuth-configured account (or use an IdP account with no matching CloudStack user).

2. Log in via the IdP with valid credentials: the code exchange succeeds (verifyOAuthCodeAndGetUser returns the correct email), but oauthlogin fails downstream because OAuth2UserAuthenticator.authenticate() can't find a matching account (userAccountDao.getUserAccount() returns null) — note this returns false before verifyUser() is ever called, so the cached token is never cleared.

3. Do not restart the management server.

4. Fix the mismatch, then perform a genuinely fresh IdP login (new authorization code) and retry.

5. Issue gets resolved if the management server is restarted

Logs

root@Cloudstack-422-before:/home/ubuntu# cat     /var/log/cloudstack/management/management-server.log |grep -i "logid:84fb4f98"
2026-08-12 08:05:42,795 DEBUG [c.c.a.ApiServlet] (qtp659590237-697:[ctx-95f375f8]) (logid:84fb4f98) ===START===  192.168.55.207 -- GET  provider=keycloak&secretcode=031a66aa-7525-b93e-3757-73350343db82.XbFFhkc0E7t7nZJ_7joLuMwU.5ed14f93-3977-4527-9649-c88da3e7be55&domain=d1&command=verifyOAuthCodeAndGetUser&response=json
2026-08-12 08:05:42,796 DEBUG [c.c.a.ApiServlet] (qtp659590237-697:[ctx-95f375f8]) (logid:84fb4f98) Authentication failure: Unable to verify the code provided
2026-08-12 08:05:42,796 DEBUG [c.c.a.ApiServlet] (qtp659590237-697:[ctx-95f375f8]) (logid:84fb4f98) ===END===  192.168.55.207 -- GET  provider=keycloak&secretcode=031a66aa-7525-b93e-3757-73350343db82.XbFFhkc0E7t7nZJ_7joLuMwU.5ed14f93-3977-4527-9649-c88da3e7be55&domain=d1&command=verifyOAuthCodeAndGetUser&response=json


root@Cloudstack-422-before:/home/ubuntu# cat     /var/log/cloudstack/management/management-server.log |grep -i "logid:2a077ac1"
2026-08-12 08:06:03,408 DEBUG [c.c.a.ApiServlet] (qtp659590237-694:[ctx-9bb94840]) (logid:2a077ac1) ===START===  192.168.55.207 -- GET  provider=keycloak&secretcode=a51ebc47-eac5-a5b2-ccc5-c38f10a6a3c1.XbFFhkc0E7t7nZJ_7joLuMwU.5ed14f93-3977-4527-9649-c88da3e7be55&domain=d1&command=verifyOAuthCodeAndGetUser&response=json
2026-08-12 08:06:03,409 DEBUG [c.c.a.ApiServlet] (qtp659590237-694:[ctx-9bb94840]) (logid:2a077ac1) Authentication failure: Unable to verify the code provided
2026-08-12 08:06:03,409 DEBUG [c.c.a.ApiServlet] (qtp659590237-694:[ctx-9bb94840]) (logid:2a077ac1) ===END===  192.168.55.207 -- GET  provider=keycloak&secretcode=a51ebc47-eac5-a5b2-ccc5-c38f10a6a3c1.XbFFhkc0E7t7nZJ_7joLuMwU.5ed14f93-3977-4527-9649-c88da3e7be55&domain=d1&command=verifyOAuthCodeAndGetUser&response=json

What to do about it?

Expected: The new code is validated against the IdP's token endpoint independently.
Actual: The plugin never makes a second token-exchange call — it serves the result off the token cached in st