Credentials

Introduction 

It is a common requirement to need to include sensitive information such as API tokens and passwords in actions. As other users can see action configurations, Tines provides the CREDENTIAL formula key which allows users to reference this sensitive information without exposing the value in Tines. When an action containing this CREDENTIAL formula key runs, Tines will substitute in the corresponding credential value. This means that sensitive data does not need to be stored as plaintext in Action configuration options or in a resource.

Creating a Credential 

From the credentials page, select "New credential". You will then be prompted to choose the credential type.

Tines supports the following types of credentials:

and additionally has product-specific credential flows that will guide you through the credential creation process per product.

🪄Tip

Sharing a Credential 

Credentials will, by default, only be accessible to the Team they are created within. Credentials can be configured to be shared with all other teams in the tenant by selecting the 'All teams & drafts' access option or with specific teams. Users can only edit these settings if they have the 'Manage credentials' permission, which corresponds with the Team admin role. Users can only share the credential with teams for which they have the 'Manage credentials' or 'Update credentials' permissions, which correspond to Team admin and Editor roles.

Need to share with other teams? Reach out to the team to discuss adding the feature to your Tines tenant.

Using a shared credential 

Stories that call Credentials with the same name as Credentials shared across multiple Teams will use the Credential located within the same Team as the Story.

You can view all credentials available to your team by clicking the "Shared with this team" section in the credentials page. You will not be able to view or modify the contents of the credential unless you have the relevant permissions in the team owning said credential.

Restricting a credential 

In order to use credentials in an outbound request, domain restriction must be defined. You can specify multiple space-separated domains or URL paths, and domain matching supports wildcards.

Domain restriction can only be changed by the credential creator, users with the 'Manage credentials' permission, which corresponds with the Team admin role, and tenant owners.

Credentials that do not have a domain restriction defined will only be usable in functions that do not expose the credential value. See the allowed functions a credential can be used in below:

AES_DECRYPT
AES_ENCRYPT
HMAC_SHA1
HMAC_SHA1_BASE64
HMAC_SHA256
HMAC_SHA256_BASE64
JWT_SIGN
RSA_ENCRYPT
RSA_DECRYPT
RSA_AES_HYBRID_ENCRYPT
RSA_AES_HYBRID_DECRYPT
SIZE
ZIP

Legacy tenants

Tenants created before May 17, 2024 12:00 UTC can opt in to the above behavior via a tenant-wide setting Credential Access.

Before opting in at the tenant level, we strongly recommend enabling this behavior at the credential level to reduce the risk of story breakage. Checking the Restrict direct access box will restrict credential usage to only the function list above and specified domains for the credential.

Once all credentials have Restrict direct access turned on, we recommend enabling the tenant-wide setting, which will update your tenant to the non-legacy behavior described above, ensuring any new credentials created mandate defined domain restriction to be used in outbound requests.

Credential metadata 

Oftentimes, credentials will have relevant, non-sensitive information that must be referenced when using them, such as a domain, account number, or username. You can store this data in a key value format as credential metadata.

You can refer to credential metadata using the INFO formula key, for example INFO.credential.jira.metadata.domain.

Credential test and production accounts 

If you are using change control in a story, you may want to test changes with your developer environment before deploying them to the live story. You can define test credentials in the Test Details tab of the Credential. In stories with change control enabled, the Test Credential will be used in the Test story version by default. See our change control section for further details.

See where credentials are used 

Select the Actions tab to view a list of actions across your tenant using the credential. You can further select any action to view the story in more detail.

Security Considerations when using credentials 

While this method dramatically increases the security of secret information in Tines, like any piece of security, it’s not absolute. For example, suppose Tines is interacting with a 3rd-party service. In that case, the service may insecurely include the credential’s value in its response, which Tines will then include in an emitted event. However, Tines does build in flexible options for you to reduce visibility of sensitive data, such as customizing an action's event output to modify the event data the action would produce and remove sensitive data for example.

Was this helpful?