Learn more about Jira Cloud products, features, plans, and migration.
Integrate Jira Cloud with Confluence, development tools, apps, and self-hosted tools using OAuth and feature flags.
Control who has access to your Jira Cloud products and give them the right permissions to perform their role.
Learn how to set up, customize, and manage Jira Cloud projects.
Explore issues, issue types, issue custom fields, issue screens, custom field context, and issue field configurations in Jira Cloud.
Define the lifecycle of your work and learn about issue workflow schemes and the issue collector.
Learn more on how you can set up Jira Cloud for your team.
This page refers to application links between Atlassian products only. For more info about links to third-party apps, check out Jira Rest API OAuth Authentication.
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 Server and Jira allows you to view branches, commits and pull requests that correspond to your stories in Jira.
Before you begin
If you’re looking to integrate Atlassian cloud and Data Center or Server 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
Create an application link
Log in to Jira as a user with 'Jira Administrator' permissions.
Choose > Products. Select Application Links in the left menu.
Select Create link.
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 or Server 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.
Select Continue to review connection details. Here are some options you’ll see on this screen:
If you check The servers 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 servers 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 servers) using the Make Primary link. See Making a primary link for links to the same application type for more information.
Atlassian's application links provide both OAuth and OAuth with impersonation authentication types:
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 Server, 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.
Having trouble integrating your Atlassian products with application links?
We've developed a guide to troubleshooting application links, to help you out. Take a look at it if you need a hand getting around any errors or roadblocks with setting up application links.
Was this helpful?