Affects Version/s: 14.5.0, 5.5.1, 6.0.0, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199
Sprint:AM Sustaining Sprint 55
Support Ticket IDs:
Needs QA verification:Yes
Are the reproduction steps defined?:Yes and I used the same an in the 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)
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)
This problem is not there in 13.5.1 and see in 13.5.2 and also 6.0.0.x (188.8.131.52) (for those tested)
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)
Issue is not seen in 13.5.1 but in 13.5.2 and later AM (due to the change to optimize Stateless CTS)
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.
Grant Expiry calculation considers refreshtoken but for grant w/o need for refresh token this is wrong.