I’m working to integrate Jira Cloud with one of our applications.
The use case is something like this, when a user performs certain actions in our application, we need to create an issue in the Jira cloud.
What I could understand from the documentation is that Jira Cloud REST API calls can be authorized in two ways, using basic auth and OAuth 2.0. However, each of the approach involves manual user input. For the basic auth user needs to generate and share the APIToken and for OAuth the the user needs to install the OAuth 3LO app and share the client id and secret. Currently we do not have an OAuth 2.0 (3LO) app.
Is this understanding correct? Or is there an approach involving very limited manual user intervention?
You are correct about API token generation. This auth mechanism is appropriate mainly for getting started with the REST APIs or for individuals performing scripting on their own site. When you want to share with other people, OAuth 2.0 is the right mechanism. Install of a properly configured OAuth App does not require any “install” or exchange of client id/secret, just a simple UI to “grant” the appropriate scopes:
With simple “accept” vs “cancel” options, this is the simplest way that users can get access to an app. The trick is to use the instructions for distributing an OAuth app.
Thanks for your suggestion, I was able to create one such OAuth app and connect to the Jira Cloud REST APIs.
I need one clarification around OAuth app though! I’m trying to consume this app without storing any user secrets (like auth code, bearer token or refresh token) so, whenever I need to access Jira APIs, I would be initiating the OAuth flow by redirecting the user to the authorization url as described here. But, the problem is that this consent form appears again and again for the same user even though the user has already granted access.
I know the alternative is to get and store the refresh token and use that to get the bearer token, however I’m trying to find a solution wherein I don’t have to store any user secrets.
I see. I confirm that Atlassian’s OAuth implementation won’t work without the ability to store secrets. I believe that some grant flows in OAuth can work that way, but we have not implemented them.
Beyond OAuth, I can’t think of any way that would support that constraint.
API tokens are just direct user secrets.
Connect JWT requires per site (tenant) secrets.
Forge manages Atlassian auth for you so you don’t store secrets, but it raises the issue of needing to auth to your external product.
I don’t think we have an answer for you. Can you explain more about your constraints? Why no user secrets in your product?
The approach without storing secrets is something I’m aiming for if possible to keep the flow simple at the client side app. But, its not a deal-breaker.
On a separate note, I understood from access token response that it is valid for 3600 seconds. Is there any way to customize the lifetime of access token? And what is the validity of refresh token?
Thanks for your patience @NawazPasha, I wanted to wait for this announcement before explaining:
Back to your questions:
I understood from access token response that it is valid for 3600 seconds. Is there any way to customize the lifetime of access token?
No. Your client should use the refresh token when it needs to use APIs for longer than the access token lifetime.
And what is the validity of refresh token?
Previously forever. As of today and the above announcement, 30 days or 2592000 seconds. So, for 30 days, you can exchange the same refresh token for new 3600 sec access tokens. Each time you exchange the refresh token for an access token, you are also given a new refresh token with a refreshed lifetime of 30 days. That way you can keep the refresh token fresh.
Can the redirect_uri of OAuth app, the one that we specify as a Callback URL be dynamic?
What I mean is, can we have a callback URL like this “https://uipath.com/{account}/product” which will match and redirect to with any value filled in place of {account}?
No. Atlassian’s implementation expects a static URL.
Atlassian expects the state parameter would be used for that kind of stateful redirection. I think this use of state is pretty common for OAuth clients. General OAuth documentation may better explain how to use state for redirection.
