I have a use case which requires me to integrate my application to Jira and vice-versa.
As far as I was able to gather information, it seems that I am only able to authenticate my application through basic auth with an API token or OAuth 2.0 (3LO). The latter is more secure as the integration is not just a simple script. However, in both cases it looks like the operations would be executed as the user who created the token/OAuth 2.0 (3LO) app in Jira.
Is there a method of authentication which will enable the external application not to act on behalf of the user but as a separate entity?
If there is no such possibility what would you advise me to do? Also, are you planning on such feature?
Welcome to the Atlassian developer community @KirilSimeonov,
Short answer, no for both API Tokens and 3LO. The current implementation of API Tokens for Jira are “personal”, tied to the user who creates the token. Meanwhile, 3LO is inherently a user-centric authorization. The proper flow would be client-credentials-grant-type, which has been raised several times on the community.
Please watch, vote, and comment on ECO-95. (Edit: sorry, wrong 2LO issue initially linked.)
The most viable option would be Forge Remote. You said, “your application” so I assume you do control both sides of the exchange, for which Forge Remote is appropriate. In the language of Forge, the “impersonal” API requests should be executed asApp.
Thanks for this rapid reply.
Unfortunately, I do not control both sides of the exchange - we provide a SaaS to our customers, some of which might use Jira. Therefore, I control the external application, they control their Jira.
In this context what would be the most viable solution? Also, this exchange should happen both ways - e.g. the application I control would need to create entities in the customers Jiras but also their Jiras would be able to create entities in my external app. Would this happen through a webhook? If so, can the webhook be restricted to a certain project (I didnt find such option)
Sorry for being unclear about “both sides”. You may not control the Jira Cloud instances, but you can control a Forge app, and you just confirmed you do control your SaaS app (in contrast to building an integration between Jira and a SaaS you don’t control). Forge Remote (linked above) is still the most viable solution with the constraint of asApp.
In terms of the exchange in both directions, here’s the general approach:
From your SaaS events to Jira, there’s a little less “opinion”. Your SaaS will need to perform a unique authorization flow to obtain a Forge Invocation Token (FIT), which your SaaS can use to make arbitrary REST API requests. For details see Forge Remote docs on calling product APIs.
I realize this could be rather counter-intuitive because you would normally build an integration into your SaaS. With Forge, you will build much of the auth & processing on Atlassian. 2LO would probably be more straightforward but it’s just an open issue right now; whereas, Forge and specifically Forge Remote already exist.
Thank you for the detailed explanation. I will need to have an in-depth look into the JIRA documentation for Forge and Forge Remote and then we will decide which approach to go with (Forge or 2LO).
Just one last question maybe, because the Forge apps is something new to me - my clients would need to create Forge (Remote) apps which will communicate with my external application and basically most of the auth & processing will fall on their side? Or do I completely missed the point? Again, I haven’t checked the docs yet, but would love to know this upfront.
@ibuchanan Thank you for the detailed explanation. I will need to have an in-depth look into the JIRA documentation for Forge and Forge Remote and then we will decide which approach to go with (Forge or 2LO).
Just one last question maybe, because the Forge apps is something new to me - my clients would need to create Forge (Remote) apps which will communicate with my external application and basically most of the auth & processing will fall on their side? Or do I completely missed the point? Again, I haven’t checked the docs yet, but would love to know this upfront.
No worries. A lot of our docs seem to assume developers already know our products and cloud infrastructure from a user perspective. There are no “stupid questions”.
A Forge app is something you would build and deploy into Atlassian infrastructure. Then you can also offer it for installation in Atlassian Marketplace to help drive awareness. Customers won’t really have to do anything technical. No copy/pasting of API Tokens or Client id/secrets. And nothing for them to worry about running; it’s all inside our Cloud. They just “install” the app, with maybe some configuration steps to map to the right tenant on your SaaS. Our customers know apps well and, from their perspective, they have come to expect this model for integration. Overall, Forge trades some additional overhead in developer experience (compared to the relatively simpler OAuth) for a very compelling customer experience.
The docs on “why build with Forge” might be the best start for understanding the Forge model (beyond my attempted summary). And to firm up what you read, I think you’d find it takes less than an hour to follow our “Forge Quest” tutorial and run through the dev loop of Forge. Doing so will probably make the infrastructure implications clear. And, parallel to the technical considerations, you may want to consider the legal & privacy guidelines, especially our shared responsibility model.