Closed alvaro-nogueira closed 2 years ago
@alvaro-nogueira I just tested the Messages Sample without any changes and the refresh token is returned in the response as expected.
If you made any changes to the default sample then please provide a minimal reproducible sample so I can troubleshoot. The description you provided is quite minimal so I'll need the reproducible sample to see exactly your configuration.
Just to clarify, I just ran the default authorization server with:
./gradlew -b samples/default-authorizationserver/samples-default-authorizationserver.gradle bootRun
Called the /oauth2/token endpoint
curl --location --request POST 'http://localhost:9000/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=messaging-client' \
--data-urlencode 'client_secret=secret' \
--data-urlencode 'grant_type=client_credentials'
And the response:
{
"access_token": "eyJraWQiOiI5Y2Y2YWJhMy1lOTZkLTQxYTQtYTQwMi1mNzRjMGQ3OWJkN2YiLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJtZXNzYWdpbmctY2xpZW50IiwiYXVkIjoibWVzc2FnaW5nLWNsaWVudCIsIm5iZiI6MTY0ODY0MzgyMSwic2NvcGUiOlsib3BlbmlkIiwibWVzc2FnZS5yZWFkIiwibWVzc2FnZS53cml0ZSJdLCJpc3MiOiJodHRwOlwvXC9sb2NhbGhvc3Q6OTAwMCIsImV4cCI6MTY0ODY0NDEyMSwiaWF0IjoxNjQ4NjQzODIxfQ.U-bxTvFoFP1B4Gh7CFfuZ8P78sed-sfPyZBUZBwq81CDaUU7jt9PsANctbrb5syoyj7wHcmoTfsx2MjkTxFVhjvZCq7ZvnuEY4g2Yt2S7GcHAD4DkCkr2li7ksJAC97Kiok6ujwbP-UdJ6YBWq8QC8p58I4P2woFTqhhAvFXsGc3kD-hyb9wGXAaUrt5K3pvpWI8bZorr1_cEpba0lwJzrh7MKVh1j58ix3QFQi1ioZTEz_CG5y17PwpZG9fLi9mId7C_SX2JQpzoaEIjE_FL2VAbbTUOBTaxO9LKclo1JH_1W69j6KGksBl95AyATXkrypE0dhYcSTtXis7mZPNrw",
"scope": "openid message.read message.write",
"token_type": "Bearer",
"expires_in": 299
}
Maybe I'm doing something wrong.
I believe that I have read elsewhere that refresh tokens are only applicable to the authorization code grant flow, as the client credentials grant flow doesn't need it as the caller must by definition have the client credentials already and can use those to request a new access token.
That said, I too would like the ability to have a refresh token in the belief that it is more secure to persist a (one-time) refresh token client-side than to persist the client credentials. For example, we have a situation where an admin user logs in to one of our (kiosk) apps to set it up. Once the app is set up, the app logs the admin user out and switches to running with client credentials, so that actions performed on the kiosk are not associated with the admin user.
We would rather have the app discard the client credentials once it has obtained an access/refresh token pair, relying only on the refresh token when the access token expires.
@scopendo Thats right, the client credentials flow does not issues a refresh token RFC6749 section 4.4.3.
Describe the bug A just cloned the project and ran the default-authorizationserver sample and the refreshToken is not issued, I changed the client Authentication Method to 'CLIENT_SECRET_POST' and the problem persist.
To Reproduce Just run default-authorizationserver sample and call /token with the credentials in the docs.
Expected behavior The authorizationGrantType REFRESH_TOKEN is explicit configured in the RegisteredClient, so the refreshToken is expected in response.