Link Atlassian applications to work together
Atlassian applications work together to provide best of breed integrations to streamline your software development or other projects.
You get Jira Software and Confluence or any of the Atlassian developer tools working together by creating an application link between them. See how to do that below.
We recommend that you use OAuth authentication for application links, because of the greater security inherent with that protocol. We don't recommend using the Trusted Applications or Basic Access authentication types anymore.
If you need to update an existing application link see OAuth security for application links.
If you want to connect Jira Software to Bitbucket Cloud see Connect Bitbucket and Jira.
Link from Jira applications
- Go to the admin area in Jira Software and click Application links.
- Enter the URL for the remote application you want to link to and click Create new link.
- Complete the application link wizard. You must make use of the automatic link-back from the remote application to get full integration (you'll need system administrator global permission for that).
Link from other Atlassian products
To create an application link from other Atlassian applications, just go to the admin area of one of them.
For specific instructions see:
- Link to server apps from Atlassian Cloud apps (on this page)
- Confluence server
- Bitbucket Server
- Bamboo server
- Fisheye
- Crucible
Link a single application to multiple applications
You can link the same application in multiple other applications. For example, you can have one Confluence instance and link to it from Jira and Bitbucket, or from multiple instances of Jira. Although we’re creating a link between the two applications, they’re not restricted from receiving more links.
Link Atlassian Cloud applications with server applications
You can link Atlassian Cloud applications, such as Jira Software Cloud or Bitbucket Cloud, with server applications such as Bitbucket Server and Fisheye.
There are some things to consider:
- You'll have to add the domain name of the cloud instance as a rule (that accepts incoming requests) to the server application's whitelist.
- For a cloud application to use the full functionality available with the server application, the server application must be accessible through the ports specified in the Compare Atlassian cloud vs server page. If you want to use HTTPS you'll need to use a valid SSL certificate (which is not self-signed) to get the full functionality available.
- Jira Cloud 2-legged OAuth without impersonation is available and is required for the Development Panel in Jira issues. See Impersonating and non-impersonating authentication on this page.
- Jira Cloud doesn't allow 2-legged OAuth with impersonation as noted in Restricted Functions in Jira Cloud.
For more information, see Link to server apps from Atlassian Cloud apps.
Impersonating and non-impersonating 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.
When you're not an admin on both applications
Where an admin of two applications creates a link between the two, the Application Links plugin will create both incoming and outgoing links between the applications and will also configure authentication on both links. This diagram illustrates this 2-way scenario:
However, if you are an admin on only one system, you can still create an application link, but the Application Links plugin will create an outgoing link only, and the link won't have any authentication configured:
In this scenario, the application where the link originates can access publicly-accessible data from the other application. For example, this type of link could allow a Confluence application to include a link to a Jira Software issue, but you wouldn't see restricted issue information in Confluence until you authenticate with Jira Software.
If you create an application link and aren't an admin on both applications, you can complete the link by signing into the other application with admin permissions (or having an administrator on that application sign in) and then create a link back to your application.
Relocate an application link
You may need to update an application link if the remote application has changed to a new address.
You may see a message if:
- The remote application can't be reached: you should check your network configuration and ensure that your remote application is running.
- The remote application has changed to a new address.
If the address has changed, you just need to click Relocate in the message, enter the new URL for the remote application of your application link, and click Relocate.
Delete an application link
- Log into your application as an administrator.
- Go to Application Links in the left-hand panel.
- Choose Delete from the Actions menu for the link.
The application will attempt to contact the remote application to delete the link. You should delete both ends of the link before recreating it.
In some cases, it may not be possible to automatically delete the link from the remote application. You'll need to log in to the remote application as an administrator and verify that it has been deleted correctly.