Uploaded image for project: 'Keycloak'
  1. Keycloak
  2. KEYCLOAK-5280

New access tokens can be obtained with an access token

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Done
    • Affects Version/s: 3.1.0.Final, 3.2.0.Final
    • Fix Version/s: 3.3.0.Final, 3.4.0.CR1
    • Component/s: None
    • Labels:
      None
    • Security Sensitive Issue:
      This issue is security relevant
    • Steps to Reproduce:
      Hide

      Steps to reproduce (I tested this with a clean setup of Keycloak 3.2.0-Final and 3.1.0-Final):

      1. For this example 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.
      Show
      Steps to reproduce (I tested this with a clean setup of Keycloak 3.2.0-Final and 3.1.0-Final): For this example 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. 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 ` 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 ` You will now have a response including a new access- and refresh token pair.
    • Docs QE Status:
      NEW
    • QE Status:
      NEW

      Description

      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.)

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              sthorger@redhat.com Stian Thorgersen
              Reporter:
              btoersche Bart Toersche (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: