OAuth security for application links
When you connect Atlassian applications using application links you get the security of the industry-standard OAuth authentication protocol.
For version 5.2 and later, application links no longer support the Trusted Applications or Basic Access authentication types.
To update an application link to use just OAuth, see Update application links to use OAuth.
If you want to create an application link between two Atlassian applications, see Link Atlassian applications to work together.
OAuth security models
There are two OAuth security models that you can use with Atlassian application links:
OAuth authentication | OAuth with impersonation | |
|---|---|---|
| Description |
|
|
| Benefits |
|
|
| Requirements |
|
|
You shouldn't link to a non-Atlassian application using OAuth authentication, unless you trust the other application. Linked applications have the ability to use OAuth to impersonate users and so are a potential security risk for the applications they connect to. If your server is compromised, the data there and on linked servers is at risk.
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.
Update an existing link to use OAuth
You may need to update an existing application link to use OAuth authentication when:
- you upgrade an Atlassian application to a version that uses version 5.2, or later, of application links. See the Application links version matrix.
- the existing link uses Trusted Applications authentication, but your team can't see summary information from a developer tool such as Bitbucket Server in the Development panel in Jira Software issues.
- an existing application link uses OAuth, but your team can't see the details dialogs for the Development panel in Jira Software issues.
- you use a plugin that requires the OAuth authentication type.
Here's how to do that in Jira Software, but the process is much the same for other Atlassian server products:
Begin in the local application
Go to the 'Configure Application Links' page in the admin area of the local application.
You may see a DEPRECATED lozenge beside links that need to be updated.
In the 'Edit' dialog, set the local authentication for the link under 'Connections':
Choose either:
- OAuth if the applications have different userbases.
- OAuth (impersonation) if both applications share the same userbase (typically managed with an external directory using LDAP).
See OAuth security for application links for more information.
Make sure that that the authentication matches for the local and remote ends of both the incoming and outgoing directions.
Click Save changes.
Now, in the remote application
Go to the 'Configure Application Links' page in the admin area of the remote application. Choose the instructions column here that matches the UI you see (they both achieve the same result):
In the 'Edit' dialog, set the local authentication for the link under 'Connections':
Choose either:
- OAuth if the applications have different userbases.
- OAuth (impersonation) if both applications share the same userbase (typically managed with an external directory using LDAP).
See OAuth security for application links for more information.
Make sure that that the authentication matches for the local and remote ends of both the incoming and outgoing directions.
Click Save changes.
In the 'Configure' dialog, click Outgoing Authentication and then the OAuth tab:
Now, select Enable 2-Legged OAuth, assuming that the applications have different userbases.
Optionally, select Enable 2-Legged OAuth with impersonation, if both applications share the same userbase (typically managed with an external directory using LDAP).
Click Update.
Now, click Incoming Authentication and then the OAuth tab:
Now, select Enable 2-Legged OAuth, assuming that the applications have different userbases.
Optionally, select Enable 2-Legged OAuth with impersonation, if both applications share the same userbase.
Click Update.
Note that:
Users who can see summarized data in the Jira Software Development panel may not have permission to see all the information that contributed to those summaries and that is visible in the details dialogs (for example, for branches, commits and pull requests). That is, the details dialogs respect the access permissions that users have in the connected applications.
Your team members must have the 'View Development Tools' permission in Jira Software to see the Development panel for an issue.
If you run an application on port 443, you must use a valid SSL certificate (which is not self-signed) to get the full functionality available.