Hi, I would like to report some unexpected behavior while requesting access- and refresh token pairs. It is possible to obtain a new access- and refresh token pair using only an access token. To describe this more thoroughly; If someone obtained a valid access token s/he can obtain a new access- and refresh token pair without ever knowing the refresh token. The problem is that refresh tokens never leave the client except when requesting a new one at the authorization server. However, the access token is sent to resource servers for obtaining resources (obviously). But now a resource server is actually able to obtain a new access- and refresh token pair on behalf of the user as well, which was never the user's intention (since it can keep a valid token indefinitely by refreshing it). Of course, since the resource server doesn't have client credentials for private clients it cannot obtain a new access- and refresh token pair for those. However, it can do so for public clients as only their name is known. (In fact, it is available in the "azp" claim of the access token.) Steps to reproduce (I tested this with a clean setup of Keycloak 3.2.0-Final): 1. We will use the admin-cli client and the admin account. You can do this with any client and account, but since this is already set up for this particular example, it makes things a bit more easy. 2. Using the admin account, fetch a new access- and refresh token pair using any grant type. We will be using the password grant: curl --data "client_id=admin-cli&grant_type=password&username=<admin_ uname>&password=<admin_pw>" http://localhost:8080/auth/ realms/master/protocol/openid-connect/token 3. Grab the access_token value from the response and perform a refresh grant using this access token: curl --data "client_id=admin-cli&grant_type=refresh_token&refresh_ token=<grabbed_access_token>" http://localhost:8080/auth/ realms/master/protocol/openid-connect/token 4. You will now have a response including a new access- and refresh token pair. This unexpected behavior can be solved by either checking the "typ" claim to be set to "Refresh", or, when time allows, using a different signing secret for the access- and refresh tokens. I would prefer the latter solution. Thanks in advance, Bart Toersche