Use AppLinks to link to Atlassian products

Application Links (sometimes called app links) is a bundled app that allows you to set up links, share information, and provide access to certain resources or functionality across multiple Atlassian products. We recommend using OAuth authentication for application links because of the greater security inherent with that protocol. We no longer recommend the Trusted Applications and Basic authentication types.

Linking Jira to other Atlassian products allows you to include information from those products directly in Jira projects and issues. For example, if you link Jira to Confluence, you can include shortcuts to Confluence page links when creating or editing a Jira issue. Linking Bitbucket Data Center and Jira allows you to view branches, commits and pull requests that correspond to your stories in Jira.

We recommend using apps to link Jira to products such as Salesforce or Zendesk. For products that don't have a supported Jira integration, you can create a custom application link.

Before you begin

Linking from Cloud to Data Center instances

If you’re looking to integrate Atlassian Cloud and Data Center products that live in your network, you can avoid allowlisting incoming connections and IP ranges (required when linking from cloud products) by using application tunnels. Learn more about application tunnels

Linking to a cloned site

Creating an application link between a site and its clone (a Jira site exported from the source site and then imported onto a second site) isn’t supported. To work around this issue:

• Change the Data Center ID if one of the sites is Jira Data Center, or

• Perform a cloud-to-cloud migration instead

Create an application link

1. Log in to Jira as a user with 'Jira Administrator' permissions.

2. Choose > Products. Select Application Links in the left menu.

3. Select Create link.

4. Choose the type of link:

   • Tunneled application link: This link reuses an existing application tunnel to forward the traffic to your network. Application tunnels can only be used to link to Atlassian Data Center products.

   • Direct application link: This link connects to Atlassian products or external applications directly. It needs to be able to reach them, which might require opening your network for incoming connections. When adding the Cloud URL, use the https://instance.atlassian.net. If the https:// is not used, the link will not be completed.

5. Select Continue to review connection details. Here are some options you’ll see on this screen:

• If you check The data center have the same set of users..., then this link will be configured using OAuth (with impersonation) authentication.

• If you are not an admin on both data centers you won't be able to set up a 2-way (reciprocal) application link. If you want to go ahead and create a 1-way link anyway, clear the I am an administrator on both instances checkbox.

6. Use the wizard to finish configuring the link. If the application you are linking to does not have the Application Links plugin, you must supply additional information to set up a link with OAuth authentication.

When you complete the wizard, the Application Links plugin will create the link between your applications using the most secure authentication method that is supported between the two applications. See the Application Links User Guide for more information.

The new link will appear on the Configure Application Links page, where you can:

• Edit the settings of the application link (for example, to change the authentication type of the link) using the Edit () icon.

• Specify the default instance if you have multiple links to the same type of application (for example, to multiple Jira d

• ata centers) using the Make Primary link. See Making a primary link for links to the same application type for more information.

OAuth authentication

Atlassian's application links provide both OAuth and OAuth with impersonation authentication types:

OAuth authentication

OAuth authentication redirects a user to log in to the remote application, after which tokens generated on their behalf are used to authorize requests made from the local application. The remote application handling the request uses the access permissions of the account with which the user logged in on that remote application.

Typical scenarios include:

• You are setting up an application link between two applications that do not share the same set of users.

• You want to continue using a link to an application that now allows public sign-on and the link was previously configured with a shared userbase. You can update your application link by changing OAuth (impersonation) to OAuth when editing the application link.

See OAuth security for application links for more information.

OAuth with impersonation

Atlassian OAuth with impersonation makes it easy for your users to benefit from the deep integrations between Atlasssian applications:

• they're automatically authenticated on the other application and don't get asked to authorize requests.

• they'll only see the information that they have permission to see. 

Impersonating authentication makes requests on behalf of the user who is currently logged in.

Note that Atlassian OAuth with impersonation can only be used for application links between Atlassian applications. Furthermore, it should only be used when the two applications share the same userbase, typically managed with an external directory using LDAP.

A typical scenario is:

• You've set up an application link but your users still have to authenticate regularly. This can occur when the application link has been configured to not share the same userbase. If those applications do share the same userbase, you can update your application link by selecting OAuth (impersonation) when editing the application link.

See OAuth security for application links for more information.

Linking to developer tools

When you create a new application link between Jira and an instance of Bitbucket Data Center, Fisheye, Crucible or Bamboo, 2-legged (2LO) and 3-legged OAuth (3LO) are enabled by default. 2LO is required for information from any of those applications to be included in the summaries in the Development panel; 3LO is used to ensure that a user has authenticated with the other applications before they get to see the information in any of the details dialogs.

Troubleshooting