--- updatedAt: 2026-07-06T08:57:37.000Z agentTools: siteIndex: https://docs.jfrog.com/llms.txt projectIndex: https://docs.jfrog.com/administration/llms.txt --- # Access Tokens You can manage Access tokens through [REST APIs](https://docs.jfrog.com/administration/reference/createtoken) or through the JFrog Platform UI - in the administration module, go to **User Management | Access Tokens**. You must have admin privileges to create admin tokens. You can also create access tokens specific to your project if you are a project admin. JFrog Access provides JFrog Products with access tokens as a flexible authentication mechanism with a wide range of capabilities. * **Cross-instance authentication** Access tokens can be used for authentication, not only by the instance or cluster where they were created but also for other instances and clusters that are all part of the same circle of trust. For more information, see [Circle of Trust (Cross-Instance Authentication) ](/installation/docs/add-circle-of-trust-certificates) * **User and non-user authentication** The case for authenticating users is clear, however, access tokens can also be assigned to non-user entities such as CI server jobs. * **Time-based access control** Access tokens have an expiry period, so you can control how long you grant access. However, you may also delegate that control to the receiving user by making them refreshable * **Flexible scope** By assigning Groups to tokens, you can control the level of access they provide. * **Pairing tokens** Manage connections between different JFrog microservices. An access token has the following properties.
Property Description
Subject The user to which this access token is associated. If the user specified does not exist, the system will create a corresponding transient user. Administrators can assign a token to any subject (user); non-admin users who create tokens can only assign tokens to themselves. When creating the access token, the subject parameter should be the same as the username. When deleting tokens, tokens of different users with the same subject name will be deleted by design.
Scope The scope of access that the token provides. For more information and configuration options, see [Create a Scoped Token](https://docs.jfrog.com/administration/reference/create-scoped-token). Since 7.21.1, access tokens are **scoped tokens**. Access to the REST API is always provided by default; in addition, you may specify the group memberships that the token provides.
Audience The set of instances or clusters on which the token may be used, identified by their Service IDs. The Service ID is a unique, internally generated identifier of a JFrog service or cluster and, in the case of Artifactory, is obtained through [Get Service ID](/administration/reference/getserviceid) REST API endpoint.
Issuer An identifier of the cluster on which the access token was created
Expiry The date and time when the token will expire. **Note** The best practice is to set the expiry value as low as possible to reduce the risk of security vulnerabilities if the token is compromised. To enhance performance, the expiry should also be lower than the threshold configured for persistent tokens to avoid unnecessary checks in the database. However, the expiry period must be long enough to complete the sequence of operations for which the token was created; otherwise, it will need to be refreshed or recreated during that sequence. For more information, see [Generating Expiring Tokens](#generate-expiring-tokens) .
Issued At The date and time when the token was created.
ID The token ID
## Access Token Creation by Project Admins Project admins can create access tokens that are tied to the projects in which they hold administrative privileges. These tokens are associated with specific roles within the project, which provide the same permissions as the given project roles have at the time the token is used. The token gets access to all Artifactory resources (builds, repositories, and artifacts). You can provide the project and role when you create new tokens. The following example shows how to use [Create Token API](/reference/createtoken). ``` curl -H "Authorization: Bearer " -XPOST "http://localhost:8082/access/api/v1/tokens" -d "scope=applied-permissions/roles:project-key:developer,qa" ``` The following example shows the response from [Get Token API](/reference/gettokens). The project field appears in the response only if a project admin created the token. ``` { "tokens": [ { "token_id": "", "subject": "", "expiry": , // optional "issued_at": , "issuer": "", "description": "", // optional "refreshable": , "project": “project-key”, }, ... ] } ``` ## Token Certificates Token certificates are the **key pair**, comprised of the private and root certificates, which is used to sign and validate tokens. The `private.key` is used to sign access tokens and the `root.crt` is the matching public key, used to verify the token's signatures. **Note** The `root.crt` will disappear from the target's trusted folder and will be placed in the Artifactory database. ### Resetting Token Certificates Administrators can force Access to reset a token certificate. To reset the token certificate: 1. Create a file named `reset_root_keys` and place it under the `/bootstrap/etc/access/keys/ directory`. 2. Reset the Artifactory service. **Note** Resetting the token certificate will effectively revoke all of the tokens that have been generated. If you want to reset your certificates but maintain the token that were created previously, you will need to copy the old `root.crt` into the trusted directory: `/var/etc/access/keys/trusted`. ### Certificates in HA - Key Pair Propagation in an Existing HA Cluster When using certificates in High Availability clusters, the `private.key` and `root.key` are propagated automatically and are updated between the cluster nodes. ## Basic Authentication A [reference token](#create-an-admin-scoped-reference-token) can be used instead of a password for basic authentication. This may be useful when you need a client (such as certain dependency managers) that only supports basic authentication to access Artifactory. In this case, it is important to access Artifactory using the same user name provided when creating the token (with `-d "username="`). For example, to use a reference token as a password to ping JFrog Platform URL, you could use: ``` curl -u: http://JFROG_PLATFORM_URL/router/api/v1/system/ping ``` ## Authorization Headers An access token can be used as a bearer token in authorization headers. This is especially useful for authenticating CI servers with Artifactory instead of using credentials, since you don't need to have a user defined in Artifactory if the group provided in `-d "member-of-groups:"` is configured in that Artifactory instance. As a result, there is no need to manage fictitious users for your different automation tools that need access to Artifactory. For example, to use an access token as a bearer token to ping Artifactory, you could use: ``` curl -H"Authorization: Bearer " http://JFROG_PLATFORM_URL/router/api/v1/system/ping ``` ## Generate Expiring Tokens **Important** When creating a token, if the token expiry is set to a value smaller than the `revocable-expiry-threshold`parameter specified in the [Access YAML Configuration](/installation/docs/access-yaml-configuration), the token will be non-revocable. By default, the value of the`revocable-expiry-threshold` parameter is set to 6 hours. For example, if you set an expiry that is less than 6 hours, the token will not be revocable until it expires naturally. Limit the validity period of a token by setting the **Expiration Time** parameter when you create the token in the JFrog Platform interface, or using the `expires_in` parameter in the REST API. The token is valid until the expiration time. The default expiry is 3600 seconds (one hour). To define a non-expirable token, set the expiry to zero. The token is valid until actively revoked. **Artifactory Administrator Only** * Only an Artifactory administrator can change the validity period of a token to any value. * Non-admin users can only set the token validity period to a value that is equal or less than the maximum allowed value set by the admin. * From version 7.21.1, this can be specified by setting the `token.max-expiry` parameter in the `$JFROG_HOME/artifactory/var/etc/access/access.config.latest.yml` file * If the `token.max-expiry` is equal to 0 (which is the default), there is no limitation to the token expiry. However, if the maximum expiry is greater than 0, the user cannot create a non-expirable token. * The `token.max-expiry` parameter must be set to a value higher than the `token.default-expiry` parameter value. * Prior to Artifactory version 7.21.1, the parameter to set was `artifactory.access.token.non.admin.max.expires.in`. Token expiration is affected by two configurable thresholds: the revocable expiry and persistency thresholds. ### Revocable Expiry Threshold The `revocable-expiry-threshold` determines whether a token can be revoked based on the token's configured Expiration Time. The threshold is the shortest token expiry period compatible with revocability. * A token with Expiration Time shorter than the threshold cannot be revoked. It expires when it reaches its configured expiry. * A token with Expiration Time equal to, or longer than, the threshold can be revoked at any time up to its configured expiry. The default value is 6 hours (21,600 seconds). The following values may impact system performance and are not recommended: * less than 2 hours. * zero (0). All tokens are revocable. This setting triggers continuous validation checks for all tokens, and negatively impacts system performance. * -1 or another negative value. This may impact security by allowing creation of non-revocable tokens. Set the value of `revocable-expiry-threshold` in the Access YAML Configuration file. ### Persistency Threshold The`persistent-expiry-threshold`defines a token’s persistency by defining the minimal expiry value a token must have in order to be saved in the database. If the `persistent-expiry-threshold` is set to a negative value, all tokens will be persistent and will be saved to the database. The `persistent-expiry-threshold` default value is set to 3 hours. Setting persistency-expiry-threshold less than or equal to zero means that all tokens that have this setting are persistent. **Important** Setting all the tokens to be persistent will affect the performance of the system, since all the tokens in the system will need to be checked directly with the database to validate that they are still persistent (including internal system ones). It is preferable to not lower this threshold to below 2 hours. #### Set the Persistency Threshold The `persistent-expiry-threshold` is set in seconds and is specified in the Access YAML Configuration file. A token with an expiry(`expiry = expirationTime-issuedAt`) below this value will not be persisted. ### Relationship Between the Two Thresholds The relationship between the thresholds is defined as`persistentExpiryThreshold <= revocableExpiryThreshold`and is validated in the Access configuration. If both `persistent-expiry-threshold` and `revocable-expiry-threshold` are positive: The `persistent-expiry-threshold` MUST be smaller than or equal to the `revocable-expiry-threshold`(if the token is not saved in the database, it cannot be a revocable token). This limitation is enforced in the code upon startup. **Note** If the persistency threshold is higher than the revocable when Access starts, an error will be logged and the thresholds will be aligned to the same number as the revocable threshold. ## Generate Refreshable Tokens As mentioned above, you can limit the validity period of a token by setting its expiry time. To allow extending access privileges of a token once it has expired, you can provide a refresh token which will generate a new token with the same privileges as the original one. This takes token management out of the hands of its issuer and delegates it to the user who received the token. **Who can refresh?** Only the instance (or HA cluster) that issued a refreshable token can actually refresh it. **Disabling the Option to Create Refreshable Tokens** From version, 7.21.1, an admin can disable the option to create refreshable tokens by setting the parameter `token.allow-refreshable` to false in the`$` `JFROG_HOME/artifactory/var/etc/artifactory/access.config.latest.yml`file. **Grace Period for Extending an Expired Token** When a refreshable token expires, JFrog Access provides the user with a grace period that essentially extends the ability to refresh the token. This is done by using the parameter `token.refresh-expiry` in the `$` `JFROG_HOME/artifactory/var/etc/artifactory/access.config.latest.yml`file. The default setting for this parameter is 24 hours. **Limitation** The integration of [SCIM](/docs/scim) ensures that an external user who has created a token will not be able to refresh the token if they have been removed from the external authentication server. However, if your organization has **not** enabled SCIM, an external user who has created a token will still be able to refresh it even they have been removed; therefore, it is recommended to implement SCIM in your system. ## Generate Admin Tokens In general, the scope for a token is defined by specifying the groups into which the token is included; however, an Artifactory administrator can also create a token with admin privileges. This can be useful for JFrog Mission Control and JFrog Xray since both of these complementary applications require admin permissions to work seamlessly with Artifactory. With this capability, when Mission Control or Xray connect to an instance of Artifactory, they can create an admin token and use that for authentication instead of using basic authentication with a username and password. To create an admin token, from the administration module, go to **User Management| Access Tokens | Generate Admin Token**. ![generate admin token.png](https://files.readme.io/44c552a401b0b036309e9658c5bd014f4368178e0d3e367497e0885e35155396-uuid-c21f75c7-8e83-211d-9737-5165bc11f20d.png) **Note** The services that appear in the screen above are only those services that are available in your JFrog Platform Deployment. ## Generate Scoped Tokens The User Management function of the Administration tab provides a centralized UI for managing *Scoped Tokens*, which are secure access tokens that provide limited and focused permissions. Scoped tokens range from identity tokens, which any user can create for themselves (see [Identity Token](/user-management/docs/identity-tokens)), to tokens that provide admin access-level permissions. In the **Administration** tab, go to **User Management | Access Tokens**. ![136877603.png](https://files.readme.io/80d76990ffad8d358b861f1992225bc7dab389f81e798b6ca76890c760a38745-uuid-9a160048-caa0-16af-5ed3-96858107c6d1.png) You can now create two types of tokens: an Admin token (which provides a range of permissions) or a User token. ### View the Scope of a Token From Artifactory release 7.46.3, you can see the scope of a token in the Access Tokens UI as a column called Scope. From Artifactory release 7.89, you can see tokens generated by Project Admins. A token generated by a Project Admin will contain project permissions and have a Project Key value and a Project Role value. It will display a value in the Project Key column, whereas for non-project admin tokens, the Project Key will be empty. ![access-scope-of-token.png](https://files.readme.io/cd7b9ff5e9f9c024537ecc61e5fdb11190a412b8ac570a25e1092b7c10e16cb0-uuid-0a541d68-05e4-dc97-5261-2a061e9f08f9.png) ### Create an Admin Scoped Token 1. In the **Administration** module, go to **User Management | Access Tokens**. From the **Token** scope field, select **Admin**. 2. In the **User name** field, enter the name of the Admin user. 3. In the **Service** field, you can either select the checkbox **All** or clear the **All** checkbox and from the list that appears in the **Service** field, select the services you will the add to this user's token. 4. In the **Expiration** time field, set the expiration time for the token (use one of the options in the field or set a custom expiration in hours). 5. Click **Generate** to generate the token. This displays the **Generate Token** window, which includes the username, scope, audience, expiration, token ID, and the actual token. ![147885946.png](https://files.readme.io/064a9c8f218a5cea65fcb195bae753b4416b396c241aea357d2224dbb99d5467-uuid-a37e8c9f-db7f-9493-6c57-7c3888f30808.png) 6. To copy the token, click the copy icon next to it or simply click **Copy**. **Important** Tokens generated here are not stored in the JFrog Platform for security reasons; therefore, make sure you copy the token before closing this window. Once closed the token will not be available. ### Create an Admin Scoped Reference Token From Artifactory release 7.38.4, you can choose whether to generate an extended token (as in the screen above), or to generate a *Reference Token*. The Reference Token is a "shortened," 128-character key, thereby providing an alias for a longer token. **Note** When creating a reference token, the maximum payload is 4,000 characters. The number or length of the groups associated with the token can affect this payload. For SAML users, Starting from Artifactory version 7.117.1, the groups association is saved in the JFrog Platform, and does not add to the payload. To support this option, the Generate Scoped Token UI includes an additional Create Reference Token checkbox. ![147885945.png](https://files.readme.io/7c1f076d1ed760648cd2824ee942b48ffebf6e4b1289fb925ccc2fec0483c608-uuid-edd6c202-6240-e676-846f-c985fdeeb1e4.png) 1. To create a Reference Token, verify that the checkbox is selected and click **Generate**. This displays the Generate Token window, which includes the username, scope, audience, expiration, token ID, the **full token** and the **Reference token**. ![147885947.png](https://files.readme.io/ca51d61f5d761a114bbcdb91126304c3c3f6e1b103091ea4daec4abfda6c9e76-uuid-c1a02e5b-ab61-31a0-3e71-3e7d87ee11f4.png) 2. To copy either the full token or the Reference token, use the **copy icon** next to the token. **Important** Tokens generated here are not stored in the JFrog Platform for security reasons; therefore, make sure you copy the token before closing this window. Once closed the token will not be available. ### Create a Project Admin Token From Artifactory release 7.89, you can generate a project administrator token. Project admins can create access tokens tied to the projects in which they hold administrative privileges. These tokens are associated with specific roles within the project, which provide the same permissions as the given project roles have at the time the token is used. You provide the project and role when you create a token. The token gets access to all relevant Artifactory resources (builds, repositories, and artifacts) based on the project roles that are defined as part of the token creation. 1. In the **Administration** tab, go to **User Management | Access Tokens**. 2. Click **+ Generate Token**. This displays the Generate Token dialog. ![generate-token-dialog-fill.png](https://files.readme.io/913cebe971a597768a653a20c6d0bfe80acc14a681e593aac759f85f84f6d65a-uuid-ee3cf126-46f6-85d5-04ff-554a888f295f.png) 3. In the **Description** field, add a description with which to identify the token. 4. In the **Token Roles** field, the available project roles are displayed. The roles available can include both global and project roles. ![token-roles-list.png](https://files.readme.io/3973801f951f5bdbaf4379d902da9c6af9a8859a7961931a0d7dc267805a21d2-uuid-b6aa4785-a246-c4fa-dfb7-121eca29859a.png) 5. In the **Service** field, you can either select the checkbox **All** or clear the **All** checkbox and from the list that appears in the **Service** field, select the services you will add to this user's token. 6. In the **Expiration** time field, set the expiration time for the token. Use one of the options in the field or set a custom expiration in hours. Note that there is a maximum expiration time of 24 hours, which is 1440 minutes. 7. Click **Generate** to generate the token. This displays the Generate Token window, which includes the username, scope, audience, expiration, token ID, and the actual token. ![generate-token-dialog-w-token.png](https://files.readme.io/c42faf8744fd5d2fdbc7324979fc52c2f40486e30a3644c6f7aa9d9e020d3cf7-uuid-0aad7cde-e476-dc0e-acc0-4e7a22bba4bd.png) ### Create a User Scoped Token 1. In the **Administration** module, go to **User Management | Access Tokens.** From the **Token scope** field, select **User**. 2. Select a user from the drop-down list in the **Users** field. You can also type the name of the user in the field to locate the user. 3. In the **Service** field, you can either select **All**, or clear the checkbox and select the services to add to the token from the drop-down list. 4. In the **Expiration time** field, set the expiration time for the token. You can use one of the options in the field or set a custom expiration in hours 5. Click **Generate** in order to generate the token. The token window appears, which includes the scope, audience, expiration, token ID, and the actual token. Click **Copy** to copy the token. ### Create a Group Scoped Token 1. In the **Administration** module, go to **User Management | Access Tokens**. From the **Token scope** field, select **Group**. 2. Select a group from the drop-down list in the **Groups** field. You can also type the name of the group in the field to locate the group. 3. In the **Service** field, you can either select **All**, or clear the checkbox and select the services to add to the token from the drop-down list. 4. In the **Expiration time** field, set the expiration time for the token. You can use one of the options in the field or set a custom expiration in hours. 5. Click **Generate** in order to generate the token. The token window appears, which includes the scope, audience, expiration, token ID, and the actual token. Click **Copy** to copy the token. ## Generate Pairing Tokens A pairing token manages connections by establishing trust between different JFrog microservices. The pairing token is an access token that is used for the initial pairing flow. Because the token is a limited-access token, it is dedicated to a specific task and short-lived. Once trust is established, the services can continue using the standard token-based authentication for communication. ### How do Pairing Tokens and Join Keys Differ? Pairing tokens replace the `join.key` that was used in the past in the JFrog Platform to link between services. This type of token is only designed to link cross-topologies (i.e., locally, and not with in a JPD). The JFrog join.key feature establishes trust between the JFrog services based on symmetric encryption (AES-128 bit or AES-256 bit). The join.key is used internally for creating trust between microservices of the same service, for example between Artifactory and Access. Pairing tokens provide pairing for a specific purpose use case. They are revocable, and are expected to be used at most once (i.e., revoked after first pairing). The default expiry setting for these tokens is 5 minutes. * The subject of the token is the same as the subject of the principal who requested the pairing token * The base URL in the extension is mandatory * The exchange URL in the extension is mandatory (since the token is signed, this URL can be assumed as trusted) * The pairing URL is optional and is used when you need to establish a two-way trust #### Master Token The result of a pairing is the *master token*, which is an access token that grants the requesting service all the actions it is required to do on the issuing service, based on the given use case. The master token is usually a strong access token that can be used for several operations and is usually a long-lived token. An admin user can revoke trust by revoking this token. #### Supported Pairing Tokens Pairing tokens enable you to connect between the following: * Between your JFrog Platform Deployment (JPD) / edge and a remote JFrog Mission Control service. The subject of the token is the same as the subject of the principal who requested the pairing token. * Between two JPDs (two Artifactory instances) that will be used to create a JFrog Archive; in this case the pairing token that is generated will be used for the API binding process. ### Pairing Tokens to Bind a JPD and a Mission Control Microservice 1. In the **Administration** tab, go to **User Management | Access Tokens | Pairing Token**. ![136877604.png](https://files.readme.io/93cf60ca6b03ed729b026ae9948f66738a3f7191fcdefc9dc76b5b4a694369be-uuid-dde7888c-caf1-5928-dc60-8901f28117f8.png) 2. In the Generate Pairing Token for field, select **Mission Control (for JPDs)**. 3. Click **Generate** to generate the token. This displays the token window, which includes the token's expiration (in seconds, set by default to 300 seconds = 5 minutes), the token ID, and the actual token, which you can copy by clicking **Copy**. ### Pairing Tokens to Set up Cold Storage (Using the API) 1. In the **Administration** tab, go to **User Management | Access Tokens | Pairing Token**. 2. In the Generate Pairing Token for field, select **Cold Storage**. 3. Click **Generate** to generate the token. 4. This displays the token window, which includes the token's expiration (in seconds, set by default to 300 seconds = 5 minutes), the token ID, and the actual token, which you can copy by clicking **Copy**. 5. Next, use the token you generated above and follow the steps in [Setting Up Cold Artifact Storage Using REST APIs](/docs/archive#work-with-cold-storage-using-rest-apis). ## View and Revoke Tokens Any token created with expiry greater than the `revocable-expiry-threshold` parameter can be revoked using the [Revoke Token by ID](/reference/revoketokenbyid) REST API endpoint or in the **Access Tokens** page in the UI. Note that you can only [revoke a token](#security-restrictions) on the instance (or cluster) that issued it unless that instance is part of an Access Federation setup (which requires an Enterprise+ license). **Note** Since 7.21.1, access tokens are scoped tokens. Access to the REST API is always provided by default; in addition, you may specify the group memberships that the token provides. Administrators can set any scope, while non-admin users can only create **Identity Tokens (user scope)**. See Access Token Structure for details. A token with an expiry specified will lapse automatically upon reaching its expiry period. A token that is not expirable (i.e., was created with its `expires_in` parameter set to 0) must be actively revoked to terminate its usage. To revoke an access token: 1. From the **Administration** module, select **User Management** | **Access Tokens**. 2. From the list, select an access token and click **Revoke**. ![114760769.png](https://files.readme.io/8e6fb2f78e486795ae4aabe99135cf3fbd9b6eb2c0073073c9982f2757e83579-uuid-a0fe7826-2668-10d8-a0b8-ecbf97ba4125.png) ## Choosing Whether a Token Gets the "Force Revocable" Flag in the REST API From Artifactory 7.50.x, the "force revocable" flag in the tokens has been removed as a default setting and is now a Boolean parameter called "force\_revocable" in the Create Token REST API. (The "force revocable" flag previously determined whether to create an access token as “revocable”, regardless of any other configuration that might tell it otherwise.) When this parameter is set to true, we will add the "force\_revocable" flag to the token's extension. In addition, a new configuration has been added that sets the default for setting the "force\_revocable" default when creating a new token - the default of this configuration will be "false" to ensure that the Circle of Trust remains in place. ## Support Authentication for Non-existing Users One of the big advantages of access tokens is the fact that you can check authorization based on a group in Artifactory, rather than on a user. When creating a group token, Artifactory will authorize with the group's permissions and that authorization will only exist as long as the token is valid. This can be useful when providing access to different tools such as a CI server coordinating a build without having to manage fake user accounts. This method is also more secure since you can assign a new token for each "job" that the external tool runs. **Artifactory Administrator Only** Note that this feature is only available for **Artifactory administrators**, since non-admin users can only create tokens with themselves as the Subject. You can create a group scoped token that can be used when you want to authenticate without creating or using a specific user. The group privileges apply to the group scoped token. To create a group scoped token using the Platform UI, see [Create a Group Scoped Token](#create-a-group-scoped-token). Alternatively, you can create a group token using the [Create Token](/reference/createtoken) REST API where the scope is as follows: ``` applied-permissions/group:{group_name} ``` If there are multiple groups, the groups are separated by commas and use quotes, as in the following examples: ``` "applied-permissions/groups:group_1,group_2" ``` ``` applied-permissions/groups:"group_1,group_2" ``` **Usage Example** ``` curl -H "Authorization: Bearer $TOKEN" -XPOST "http://artifactory-up:8082/access/api/v1/tokens" -d '{"description" : "test", "scope" : "applied-permissions/groups:group_1,group_2", "include_reference_token" : "true", "refreshable" : "true"}' -H "Content-type: application/json" ``` ### Transient Users and Auto Join Groups When a token's subject is a non-existing user, the JFrog Platform creates an in-memory **transient user** during authentication. This user exists only for the duration of that session and is not saved to the database. If the token includes the `applied-permissions/user` scope—which is added automatically during OIDC exchanges that include a username—the transient user inherits all local **Auto Join** groups at authentication time. The JWT itself does not contain these auto-join groups. Because groups are applied on the fly at authentication, different Access servers may grant different permissions for the exact same token depending on their local Auto Join configurations. | Token type | Effective permissions | | :------------------------------------------------------ | :------------------------------------------------------- | | Groups-only token (no `applied-permissions/user` scope) | Explicitly mapped groups only | | Token with `applied-permissions/user` scope | Explicitly mapped groups plus any local Auto Join groups | To prevent accidental permission expansion, regularly audit your Auto Join groups—especially if you use OIDC identity mappings. ## Binding Tokens **Subscription Information** This feature is supported with **Enterprise X** and **Enterprise+** licenses. JFrog Platform supports access tokens when configuring the different JFrog products, which provides a flexible means of authentication. With the release of JFrog Artifactory 7.33.8, JFrog introduces a type of token called a *binding token*, which allows trust to be **bi-directional**. While binding was available with the older access methods (Circle of Trust, join key, etc.), it has now been implemented as part of the JFrog **Platform Deployments** function in the **Administration** tab. Binding tokens are managed through the JFrog Platform UI. Binding tokens require you to have an enabled Mission Control service, since the binding token is created by Mission Control. Token renewal is also handled by Mission Control. ### How do Binding Tokens Differ from a Circle of Trust? A "[Circle of Trust](/docs/access-tokens)" is established by sharing a public certificate among all participating instances. It is up to the service administrator to make sure that all participating instances are equipped with the certificates. This means that any instance can generate a token to be used with any other instance within the Circle of Trust. In essence, a Circle of Trust means that a service will verify access token signatures against all trusted certificates, including ones generated by other services and set as 'trusted' as part of the Circle of Trust. Binding tokens provide a narrowed trust scope for those customers that do not wish to provide full access to the other JPDs, and also full self-service for Cloud Enterprise customers that can build customizable binding to the other JPDs on their own. Binding tokens enable admins to create trust between managed JFrog Platform Deployments (JPDs) once the JPDs have been added to the Mission Control instance, thus simplifying the setup across JPDs. This makes it possible to support use cases such as Federated Repositories for Cloud customers. **Circle of Trust for Self-hosted Customers** JFrog Platform will continue to support the Circle of Trust method for Self-hosted customers that allow full access to other JPDs. From Artifactory version 7.33.8, the JFrog Platform enables you to manage your binding tokens through both the Platform UI (in the **Platform Deployments** tab in the Administration module). To create binding tokens in the UI, you will need to make sure of the following: * You have Mission Control enabled in your Artifactory * You have added JPDs to the Mission Control instance by [registering Platform Deployments](/docs/manage-platform-deployments) ### Set Up Binding Tokens for Federated Repositories This section describes the steps for setting up binding tokens for Federated Repositories. When establishing trust between the two JPDs for Federated Repositories, ensure that you add the root and intermediate certificates to the Artifactory folder, security folder, key folder, and trusted folder. **Note** Binding tokens require you to have an enabled Mission Control service, since the binding token is created by Mission Control. Token renewal is also handled by Mission Control. 1. From the **Administration** module, click **Platform Deployments | Bindings**. This displays the list of available JPDs and their bindings. 2. Click **+Add Binding | Federated Repository**. This displays the Create Binding window. ![create-binding-empty (1).png](https://files.readme.io/9f813ef0a7a0a2fc21971b465b23a424556c0f38b8b1d92d6a7f24257dbd2011-uuid-964d451a-bd56-a191-e896-b4d51f4e34cb.png) 3. In the Select JPDs dropdown list, select the JPDs - source and target - that you wish to bind to each other. 4. Click **Apply**. The Selection Summary now displays the target and source you selected. ![create-repo-binding.png](https://files.readme.io/18f5ea16b9dc325be7d404fb423f8f168da3bc4a63e3453daa27ecdc531305b9-uuid-415192b4-a278-6136-1d08-96909033c3fd.png) 5. To add more JPDs to the binding, add them in the Select JPDs field, and then click **Apply** again. 6. Click **Create** to create the new binding. The results of the bindings you created are displayed. ![binding-result.png](https://files.readme.io/5ab062f35f742ac0b11daa4395ac7b850c6cc43f4a66f806f2fe47f0fd7d85b8-uuid-1aee7f15-fe70-535a-1e70-1af4f63474b4.png) If a binding action failed, you may want to go back and verify that the source JPD is available, then try again. ### Remove Bindings Removing a binding between a source JPD and target JPD means you are deleting a bi-directional connection (from source to target and target to source). 1. From the **Administration** module, click **Platform Deployments | Bindings**. 2. In the Deployment Bindings window, select the checkboxes of the bindings you wish to remove, and then click the **Delete** button to the right of the binding. 3. If you are deleting multiple bindings, select all checkboxes, and at the bottom of the window, select **Delete**. This displays a confirmation message that asks if you are sure you wish to remove the binding. Removing a binding removes the bi-directional connection (from source to target and target to source). 4. Click **OK** to confirm. Your action is applied and the results of the unbinding are now displayed. ![unbinding-result.png](https://files.readme.io/35f337908794539e34b66d2d03ea0dd1af3abfe5bc7b4780a67169d13cc07740-uuid-e7897344-2fc7-2d01-4d8c-48bdcae8fa83.png) ## Circle of Trust (Cross-Instance Authentication) Access tokens support cross-instance authentication through a "circle of trust", which is established by sharing a public certificate among all participating instances. In essence, a circle of trust means that a service will verify access token signatures against all trusted certificates, including ones generated by other services and set as 'trusted' as part of the circle of trust. **Note** It is up to the service administrator to make sure that all participating instances are equipped with the certificates. This means that any instance can generate a token to be used with any other instance within the circle of trust. ### Why do I Need a Circle of Trust? A circle of trust is required when you have a series of JPDs that need to be accessed using a single set of credentials. For example, a single build agent that needs to upload and download from two JPD instances. By creating a circle of trust, you can ensure that one JPD instance will trust another instance’s tokens. This is achieved by sharing the public token certificate between all instances within the circle. **Note** Trusted certificates can be loaded and removed while the server is running, and do not require a restart. ![Cross instance authentication](https://files.readme.io/d8243699eab3b585a13a6f15b67cdd71a7b816c0f77528878a7b867f28ffafd3-uuid-7493160f-1d75-a650-136e-c95712691cec.jpg) ### How to Establish a Circle of Trust To establish a "Circle of Trust" between JFrog services, you will need to exchange the public token certificate between the services. Services that are within the circle of trust have complete admin privileges on each other. To exchange the certificates, you need to copy a service’s root certificate to another service’s`$JFROG_HOME/artifactory/var/etc/access/keys/trusted`folder. The service's root certificate can be acquired in the following ways: * found under `$JFROG_HOME/artifactory/var/etc/access/keys/root.crt` (requires physical access to the server) * by calling the [Get Root Certificate](/reference/getrootcertificate) REST API **Note** The `root.crt` will disappear from the target's trusted folder and will be placed in the Artifactory database. To establish a circle of trust in a Helm installation, see [Add circle of trust certificates to a Helm installation](/installation/docs/add-circle-of-trust-certificates). Trust can be created between multiple services: you need to make sure that all participating instances in the circle of trust are equipped with the relevant public keys (root certificate). Note that a trust can be unidirectional or bidirectional. The service watches a directory of trusted public keys and reloads the keys when it needs to verify a token **Renaming the source service’s certificate** Since trust can be created between multiple services, you should rename each source service’s certificate with a meaningful name. For example, if one service named “us-east” should be trusted by another service named “us-west”, then `$JFROG_HOME/artifactory/var/etc/access/keys/root.crt` `from us-east`, should be copied to`$JFROG_HOME/artifactory/var/etc/access/keys/trusted/us-east.crt`on us-west. **Use the same Artifactory userid and groupid** Make sure you give the same Artifactory`userid`and`groupid`to the root certificate in the trusted folder (`$ARTIFACTORY_HOME/access/etc/keys/trusted/*`) by comparing to the other files from the previous folder (`$ARTIFACTORY_HOME/access/etc/keys/`). ### Security Restrictions To make JFrog access tokens as secure as possible, some configured values ensure that tokens are managed and can only be used for the right purposes: * **Scope**: If the token scope is a user or a group, you must ensure that the user or group exists on all servers in the circle of trust. * **Revocability**: For security purposes, the JFrog Platform is deployed with default configurations that set every token to be revocable. However, revocable tokens are validated against the Access database, and a token created in one JPD cannot be validated against the Access database of another JPD. Do one of the following: * Set up ​[Access Federation​​](/administration/docs/access-federation) with the JPDs of the Circle of Trust. Access Federation lets you share revocable tokens and other entities among JPDs. JFrog's recommends this configuration. * Use [short-lived tokens](#generate-expiring-tokens). On each server, give the token used for the Circle of Trust an expiry that is less than the value of the `revocable-expiry-threshold` parameter in the `access.config.yaml` file. To ensure consistent, reciprocal authentication, define the same value for `revocable-expiry-threshold` on all servers in the Circle of Trust. * **Token type**: The following types of tokens are not supported in a Circle of Trust: * Reference tokens are not supported in a circle of trust (they always require the token to be in the instance’s database). * UI-generated tokens: Tokens created via the User Profile page are reference tokens and are not supported in a circle of trust. **Limitations** By default, only the issuing instance can refresh a token. For synchronizing tokens across services, see Access Federation. ## Access Token REST API You can manage access tokens through the [Access Token](/docs/access-tokens) REST API.