ARTIFACTORY: How to resolve a token with an expiration time less than 300 seconds which can be used after it expires
Introduction
When creating an Access Token with an expiration time of less than 300 seconds, there may be instances where the token can still be used even after it has expired.
In the provided example, an Access Token with an expiration duration of 60 seconds is generated through the Create Access Token API. The exact expiration timestamp for this token can be observed within Artifactory's access-security-audit.log.
- Create an access token with an expiration time of 60s and it returns a token that expires in 60 seconds.
# Create token request: curl --location 'http://<art_url>/access/api/v1/tokens' --header "Authorization: Bearer <token>" --data \ '{ "expires_in": "60" }' # Create token resopnse: { "token_id" : "0f34030e-xxx-43c4-xxx-38d7eed897b1", "access_token" : "<expire_60_token>", "expires_in" : 60, "scope" : "applied-permissions/user", "token_type" : "Bearer", "username" : "admin" } - Through the access-security-audit.log to get the token expiration is 1735886452644.
# access-security-audit.log 2025-01-03T06:39:52.645Z|20e96ae2d20324ec|198.19.249.3|admin|admin|jfac@01jesyd4b217xn1zwcnt9p13g8/users/admin|C|TKN| { "added": { "owner": "jfac@01jesyd4b217xn1zwcnt9p13g8", "created": "1735886392644", "expirationTime": "1735886452644", "subject": "jfac@01jesyd4b217xn1zwcnt9p13g8/users/admin", "scope": "applied-permissions/user", "id": "87f13f60-xxx-41ed-a12b-6bf98a451587", "type": "generic", "username": "admin" } } - Using this token to request the Artifactory API before and after the token expires, you can see that the access token can still be used after the expiration, while the token is invalid after 300s.
# The first request use the <expire_60_token> and it's within the expiration time [root@7 ~]# date +%s%3N && curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8082/artifactory/api/system --header "Authorization: Bearer <expire_60_token>" && date +%s%3N 1735886420913 200 1735886420953 # The second request use the <expire_60_token> and it's outside the expiration time, but the expiration time does not exceed 300 seconds [root@7 ~]# date +%s%3N && curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8082/artifactory/api/system --header "Authorization: Bearer <expire_60_token>" && date +%s%3N 1735886491877 200 1735886491916 # The third request returned a 401 error because the expiration time of the token exceeded 300 seconds. [root@7 ~]# date +%s%3N && curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8082/artifactory/api/system --header "Authorization: Bearer <expire_60_token>" && date +%s%3N 1735890157502 401 1735890157541 - When using the <expire_60_token> to send a request to the Artifactory for the second time, the request can still succeed even if the <expire_60_token> has expired.
Resolution
The phenomenon occurs because, upon successful token authentication, the authenticated data is cached by Artifactory. This cached data is then utilized for subsequent requests, bypassing the need to re-query the data, which enhances the speed of authentication. The default cache duration is set to 300 seconds.
Note: The cache applies exclusively to REST API requests and does not extend to interactions conducted through the user interface.
To avoid this issue, we can configure the authentication cache duration to be shorter than the minimum expiration time we intend to set for the token.
Modify the cache duration for authentication, you can add the following parameters to the properties file located in the $JFROG_HOME/artifactory/var/etc/artifactory/artifactory.system.properties file.
# example set it to 10s artifactory.security.authentication.cache.idleTimeSecs=10 # default 300s
Restart the Artifactory for the configuration to take effect.