Refresh token grant fails with "Bad credentials" after original client secret is deleted during rotation
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 52/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- java
- Ambito
- api, authentication, security
Direzione di ricerca
Start at the /oauth/token refresh_token grant handling and trace how client authentication and refresh-token validation interact during the ADD and DELETE secret rotation calls. Reproduce the sequence in the issue and compare it with related issue #4047; done means a token issued before rotation can be exchanged using the client's currently valid secret and returns a new token pair.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
When rotating a UAA client secret (adding a new secret, then deleting the original one), subsequent refresh_token grant calls fail with invalid_client: Bad credentials, even though client_id remains unchanged throughout. refresh_token is bound to the client's identity (client_id), and client authentication should be validated independently at each /oauth/token call using whatever secret is currently valid for that client — the secret rotation itself should not invalidate previously issued refresh tokens. This forces users to be re-authenticated (effectively logged out) after every completed secret rotation, defeating the purpose of zero-downtime rotation.
Environment
- UAA version: 78.2.0
Steps to Reproduce
- Generate an access_token and refresh_token via /oauth/token using grant_type=password (or authorization_code), passing client_id and client_secret (Secret A).
- Add a new secret to the same client: POST /oauth/clients/{client_id}/secret?changeMode=ADD (Secret B)
- Remove the original secret: POST /oauth/clients/{client_id}/secret?changeMode=DELETE (removing Secret A) (This happens on next secret rotation)
- Call the token endpoint using the refresh token from step 1, authenticating with the new secret (Secret B): POST /oauth/token grant_type=refresh_token&refresh_token=...&client_id=...&client_secret=
Expected Behavior
Since client_id has not changed and the caller is authenticating with a currently valid secret for that client, the refresh_token grant should succeed and return a new access_token/refresh_token pair.
Actual Behavior
The request fails with:
json
{
"error": "invalid_client",
"error_description": "Bad credentials"
}
This happens even though the client authentication itself (client_id + current secret) is valid — it appears the refresh_token is internally tied to the specific secret value active at the time of issuance, rather than to the client's identity alone.
Related
This is related to #4047, which reports a similar failure during the ADD phase of rotation (before the old secret is deleted). Together these suggest refresh_token validation in UAA may be coupling client authentication to a specific secret value rather than re-validating client identity independently on each call.
- Lingua principale
- Java
- Stelle
- 1.6k
- Fork
- 845
- Merge medio
- 2g 3h
- PR unite (30g)
- 29
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di cloudfoundry/uaa
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 38/100
cloudfoundry/uaa#4113 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
cloudfoundry/uaa#3963 ·
I maintainer di solito rispondono entro 1 giorno
-
clarification needed
Difficoltà 4/5 3-5 giorni Idoneità per principianti 38/100
cloudfoundry/uaa#3749 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
cloudfoundry/uaa#3736 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
cloudfoundry/uaa#3735 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di cloudfoundry/uaa
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
hiero-ledger/hiero-sdk-java#3010 ·
I maintainer di solito rispondono entro 1 giorno
-
Optimize consumer version heatmap aggregation to avoid repeated scansForse già presa @praykaria31 l’ha presa oggi. Apertatype/enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
Apicurio/apicurio-registry#10662 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
a:false-positive
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
I maintainer di solito rispondono entro 1 giorno
-
status: waiting-for-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
spring-projects/spring-boot#52347 ·
I maintainer di solito rispondono entro 2 giorni
-
bug untriaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
opensearch-project/opensearch-migrations#3480 ·
I maintainer di solito rispondono entro 2 giorni