[keycloak-dev] Welcome to the "keycloak-dev" mailing list

[Bart Toersche]

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