Skip to end of metadata
Go to start of metadata

Redirection Notice

This page will redirect to OAuth Security for Application Links.

When you create an application link between two applications, OAuth authentication is used by default. This authentication type lets logged-in users take advantage of all the integration points between Atlassian applications.

 

On this page:

The following types are available:

Atlassian only recommends using OAuth authentication for Application Links.

Depending on your permissions when you create an application (or the settings required in the application you are linking to), you might need to modify the authentication settings for an application link after it's been created. There are a few common scenarios in which you might need to change the configuration of an application link:

  • You've set up an application link but 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 user base, you can update your application link authentication by selecting the Allow user impersonation through 2-Legged OAuth check box on the incoming authentication settings for the application link configuration.
  • 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 authentication by clearing the Allow user impersonation through 2-Legged OAuth check box on the incoming authentication settings for the application link configuration.
  • You use a plugin that requires a specific authentication type.

Note that to get the full integration available in the Development panel in JIRA Software issues, JIRA Software must be connected with Bitbucket Server, FishEye, Crucible or Bamboo using a 2-way application link that has both 2-legged (2LO) and 3-legged (3LO) authentication enabled. See Integrating with development tools for version information and connection details.

OAuth is the authentication type we recommend. However, be aware of the following security implications:

  • Adding an OAuth consumer requires the transmission of sensitive data. To prevent 'man-in-the-middle' attacks, it is recommended that you use SSL for your applications while configuring OAuth authentication.
  • Do not link to an application using OAuth authentication, unless you trust all code in the application to behave itself at all times. OAuth consumers are a potential security risk to the applications that they are linked to because of the ability to impersonate users. If your server is compromised, the data there and on linked servers is at risk.
  • New application links now use OAuth by default and enable both 3-legged OAuth (3LO) and 2-legged OAuth (2LO).
  • When updating older application links (that perhaps used Trusted Apps authentication) to use OAuth, 3LO is enabled by default, but you need to explicitly enable 2LO using the Allow 2-legged OAuth check box in the application link configuration settings.
  • Only use the 2LO with impersonation option in the application link configuration settings if your servers both have the same set of users and the servers fully trust each other.

We no longer recommend the Trusted Applications authentication type. If you do use Trusted Applications authentication, be aware of the following security implications:

  • Trusted applications are a potential security risk. When you configure Trusted Applications authentication, you are allowing one application to access another as any user. This allows all of the built-in security measures to be bypassed. Do not configure a trusted application unless you know that all code in the application you are trusting will behave itself at all times, and you are sure that the application will maintain the security of its private key.
  • Only use Trusted Applications authentication if both your servers have the same set of users and the servers fully trust each other.

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.

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.

  • No labels