Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-13612

OAuth2 CTS Grants without RefreshToken should expire with AccessToken timeout for one-to-one mapping


    • Sprint:
      AM Sustaining Sprint 55
    • Story Points:
    • Needs backport:
    • Support Ticket IDs:
    • Verified Version/s:
    • Needs QA verification:
    • Functional tests:
    • Are the reproduction steps defined?:
      Yes and I used the same an in the description


      Bug description

      When using Stateless OAuth2 with client_credential/implicit grant type, the CTS token created is not using the access token timeout but is (access token timeout + refresh token timeout) when the OAuth2 has the "issue refresh token" enabled. This is for the CTS 1-1 model (that exists in prior 6.x/5.5x version)

      How to reproduce the issue

      As the client_credential grant or implicit does not issue refresh token and is nearly always short live and issue quite frequently, an expiry time with the 7 day refresh token will cause CTS the fill up and induce massive problems. [Impact]

      In short for grant type that DOES not generated refresh token, it seems the CTS grant token is set with the refresh token timeout (added to the access token value) (It is assuming some token refresh operation could later check the CTS grant which would not be the case since these grant does not do refresh token)

      Version affected and not affected.

      This problem is not there in 13.5.1 and see in 13.5.2 and also 6.0.0.x ( (for those tested)

      How to reproduce issue

      1. Install AM 13.5.x/6.0.0.x
      2. Create a new test realm
      3. Using the OAuth2 Dashboard and create a new OAuth2 service (for /test realm)
      (MAKE SURE to CLICK "issue Refresh Token" as this is core to the issue).
      4. Set this to stateless OAuth2 (with all the defaults)
      5. Now create a new OAuth2 Agent (myClientId) - use whatever default
      6. Now access this OAuth2 application with a client_credential grant
      7. Check the created CTS OAUTH2_STATELESS_GRANT coreExpirationTime
      Notice it is 60 min + 64200 (7 days : using the refresh timeout)

      Expected behaviour
      OAUTH2_STATELESS_GRANT for client_credential grant type just have the specified access token timeout
      Current behaviour
      OAUTH2_STATELESS_GRANT for client_credential or implicit grant type (on CTS) is "access token timeo

      Issue is not seen in 13.5.1 but in 13.5.2 and later AM (due to the change to optimize Stateless CTS)

      Work around

      May not be that great but since the conditions are

      1) OAuth2 "issue refresh token" is enabled
      2) refresh token timeout 642000 ( sec)

      so either if possible that other grant type is not used (or refresh token is not used) maybe one can try to workaround with one of the above settings to cause this not to come about.

      3) Otherwise, may external cleanup these CTS thru a external routine (assuming these token is distingushable (creationTime?) or realm or clientId.

      For Future AM 6.5, changing from 1-1 CTS Grant module to the new GrantSet model will avoid this issue.

      Code analysis

      Grant Expiry calculation considers refreshtoken but for grant w/o need for refresh token this is wrong.


          Issue Links



              • Assignee:
                chee-weng.chea C-Weng C
                chee-weng.chea C-Weng C
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: