Issues with the different authentication schemes

We are basically trying to build an integration between Jira (Cloud) and 3rd party software. Our use case is that the different 3rd party systems require access to data in Jira, for different projects. This needs to be highly automated, and not require any knowledge of (or even direct access to) Jira.

As far as I can tell there are 3 ways that I can obtain access to data in Jira:

  1. Atlassian Connect, designed for people who work in JIRA (not suitable for this use case).

  2. OAuth 2.0, which is user oriented, rather than “organization” oriented, which requires interaction, and require duplicated data, as this is already handled by our IAM software.

  3. Basic Authentication, which would technically work for our use case, at the low cost of introducing an attack vector. Which could be mitigated by restricting access to this, with for instance IP filtering, which does not seem to be an option sadly.

Neither of these approaches really work that well, Is there something I’m missing, or should I just go with basic authentication?

Kind Regards,
Mikkel Løkke

Theoretically, you could still go with Atlassian Connect, as this will create a service account for your application, giving you access to a specific instance using service credentials with permissions defined in the scope set in the atlassian-connect.json. The application itself will run on your own hardware, allowing you to expose a proxy endpoint to jira for your own applications.

To clarify how this works: you can use the instance ID + shared secret that are provided upon installation of the Connect app in your Cloud instance (posted to you via the postinstall web hook) to generate your own JWT tokens to access the Jira API. You can also create tokens that impersonate users.

The Connect application does not need to be published to the Atlassian Marketplace, you can also manually install it when enabling developer mode in the cloud instance UPM.

2 Likes