My company has Artifactory (Enterprise Plus 7.63.5 rev 76305900) which my team uses for container images and host some other large files that are too big or inappropriate for Github. I've been setting up an automated process to periodically create a new token to use in our automation jobs (so we don't have to create new tokens manually) and I've seen that the token created in the GUI (Edit Profile > Generate an Identity Token) is much different than one created through the REST API:
- The GUI generates a 64-character token which can be used with
X-JFrog-Art-Api: "{{ artifactory_token }}"orAuthorization: "Bearer {{ artifactory_token }}"request headers - the REST API generates a 757-character token which can only be used with a
Authorization: "Bearer {{ artifactory_token }}"request header
We've got a little tooling that uses a X-JFrog-Art-Api: "{{ artifactory_token }}" request header which won't work with a new token created via the REST API. The tooling can be easily changed to Authorization: "Bearer {{ artifactory_token }}" but we would like to know why the token styles are wildly different.
The token generated from the REST API is an access token and the token generated from the UI in edit profile page is a reference/identity token.
The JFrog’s Access tokens are standard JWTs and can be quite long - since they contain the token’s properties as well as additional information used to validate the token.
The sheer length of the token can create compatibility issues with various clients trying to authenticate with the JFrog platform or some clients might not even support bearer token authentication (Authorization: Bearer ).
To mitigate these length limitations, JFrog introduced the Reference/Identity Token. A Reference Token is simply a short string of characters that refers to an actual token.For more information on Reference/Identity tokens, please refer to this KB article.