How to Associate Internal User with New Jira Cloud Integration

New to Atlassian Development here. I am trying to create a JIRA integration where users in my multi-tenant app can create Jira issues through my UI. I am stuck on Authentication. I created an App Descriptor and I am able to use the shared secret to generate jwts and call REST endpoints. My question is: how do people associate the shared secret (from atlassian) to an existing user on their site? The installation is done exclusively through Atlassian, and I can’t make the association in the /installed and /enabled callbacks, since I don’t know which user on my side has just created the integration. How are other people doing this?

So you want a non-Atlassian app to act as an Atlassian user inside an Atlassian product? That sounds like you want 3LO support for the Jira REST APIs. That is on the short term roadmap: Trello we are actively working on it.

In the meantime, if you create an iframe in the Atlassian product, then you can get access to the browsing user.

2 Likes

I am a bit confused, as JIRA supports 3LO (https://developer.atlassian.com/cloud/jira/software/jira-rest-api-oauth-authentication/). What you are saying is that for my use case, you recommend 3LO as opposed to a Connect App Descriptor?

Just to clarify my use case: I have users on my site that want to be able to create JIRA issues through my UI. I tell them to:

  1. Install my Connect app on the Atlassian Marketplace (I am currently developing this)
  2. When my app is installed, I get their Client Key and Shared Secret
  3. I (somehow) store their client key and shared secret to my user model. I will use this to make requests in the future to create JIRA issues.

I am confused on step 3. The solution to this is to use 3LO, which does not require a Connect app. Does all this sound correct?

Unless there is another 3LO that I am unaware of that works with the Connect App Descriptor?

That is currently true. I would use the OAuth 1a version of 3LO for now. We intend to release a better version of 3LO based on OAuth 2 and with features that make it more like a true cloud app, but if you want to get started, the link you have pointed to is the best way to go.

1 Like

The tutorial in here https://developer.atlassian.com/cloud/jira/software/jira-rest-api-oauth-authentication/ hints that this integration is not the way to go for multi-tenant applications. It looks like going through this tutorial will help me connect to a example.atlassian.net to my application, but I am looking to allow all of my users to connect.

Specifically, going to cog icon > Applications > Application links looks like I am only going to authorize my application for this one instance of JIRA.

That is correct. That is what the trello card that I linked to you will solve when it is released for Jira. However, it will only change the way in which you direct people to a Consent screen and then get back your token, it won’t block how you then use that token to make REST API calls. That means that you could develop most of your integration now until that feature is released.

My recommendation is this:

  • If you want to get something out the door immediately. Write an App Descriptor, create a general page and direct your users there in order to perform the actions that you want them to perform.
  • There is no guarantees, but, if you want to do it in a way that would match your use case better, you can use 3LO and swap to the new way of doing 3LO when it is released. No promises as to when it will be released, but I can say that we are actively working on it.
2 Likes

Ok, so our proposed method of integration will probably be something like this:

  1. User installs our app using an App Descriptor URL
  2. We store their client key and shared secret for later use
  3. Our app renders an iframe on JIRA after they install, showing the user their client_key
  4. The user goes to my website, where they sign in and enter their client_key in a prompt that I give them
  5. I then make the association between their identity on my website, and their identity on Atlassian (from step 2).

Does this all make sense? Are there any security concerns with this approach/is there any part of this that does not seem feasible?

Thanks for your help and guidance.

Tony

I have seen this approach work well before. But I can’t tell you if it is secure without more details about the implementation. Just make sure that you require user_is_logged_in as a condition on the page and you should be able to come up with a secure redirect flow. Cheers.

1 Like