Hi,
I have an back-end application running in AWS. It reads some events and based on an internal logic times to times it decides to create new Jira issue (or update some existing issue). It already works well for me with my Jira personal access token.
I want to replace my personal access token by some other impersonal token, because of:
- I should not be the creator of these issues. They are not created by any real user, but the backend application.
- I also do not want to give to the backend application all permisions, which I have as a user in Jira. For the backend application it is enough to create and update issues in two projects.
- It is also against our internal company policy to use personal credentials for autonomous server applications.
Is there any possibility to create an API token, which will be able to create and update jira issues and which will not be attached to any real Jira user? I tried to search such possibility in Jira documentation but without success.
Hi @vvotipka, I suggest that you consider implementing a Forge app.
With Forge, we allow you to make calls on behalf of the app (see documentation) so that you don’t have to perform operations on behalf of a user. The authentication is opaque to you, Forge manages all of it and we use OAuth under the hood.
To integrate your AWS application with Forge, you can use web-triggers (to call the Forge app from your AWS backend) or Forge remote (to have Forge call your AWS backend).
Hi @BoZhang,
many thanks for your response. I spent some time to read what the Forge is and how it works. I’m not sure if I understand it well.
To be able to call JIRA REST API with token not attached to any existing user, I need:
- Introduce new technology (JavaScript) to our technology stack (my apps are written in Go).
- Build new intermediary layer which define new API (web-triggers) and translate it to the existing JIRA REST API.
- Implement the authentication on the new API (web-triggers) myself.
- Deploy this new component (the Forge app) to different cloud using different process.
And all these steps I need to do just to call JIRA REST API from my Go application. Is it correct? Or am I missed something?
Hi @vvotipka,
Yes, the list sounds correct. Given the nature of your tech stack and integration, it does sound like a good chunk of work, but I believe that it will satisfy the three requirements that you mentioned in your first post.
The alternative would be to create a 3LO OAuth integration (we don’t support 2LO for these integrations), but this will only satisfy two of your three requirements (it doesn’t satisfy the first requirement of not having a real user create issues). You will also need to manage the OAuth dance and the OAuth tokens, but you don’t need to do bullet points 1-3 in your list of steps.
I hope this helps, let me know if you have any more questions.
@vvotipka please express your interest for ECO-95: vote, watch and add a comment describing your use case and why this is important for you.
Hi @epehrson,
I’m not sure if my issue is similar to the " Client Credential Grant Flow for OAuth 2.0 for external OAuth2 apps" topic.
In my case I do not want to use client credentials.
In our company we have a background process, running continuously without any interaction with humans. Times to times a problem appears in the background process, which needs a human attention. We want to create Jira issue in such case from our background process.
For this case I want to have credentials (API token) which will be used for Jira issue creation via REST API. This token should not be connected to any person, because:
- the person will be displayed as the creator of the Jira issue, which is not true
- the personal token grants to the background process full credentials of the user which is against security principles (the application should have access limited to operations, which it really needs)
@vvotipka with the OAuth 2.0 client_credentials flow, you would be making API requests using an impersonal token, as you requested originally. The OAuth 2.0 client ID and secret is a credential pair used to obtain such short-lived tokens. Such an OAuth 2.0 client would have a system user associated, which is the user that would be displayed as having performed any action.
2 Likes