Jira Automation: Can we store the response of the web request and fetch it in the subsequent trigger

[Venkat]

Hi,

Is there a way to store the web request response somewhere and fetch it during the next time this automation runs?

My use case: I have generated an OAuth access token by sending a web request. If I am able to store it somewhere, then I need not generate it again, instead fetch it from where I have stored in the previous time when this automation was triggered.

[YY Brother]

Hi @Venkat 

Welcom to our Community.

It's not recommended to store OAuth access token in somewhere because it's a so sensitive information and usually is encrypted.

I suggest each time you need, then you fetch it.

Thanks,

YY哥

[Venkat]

Hi @YY Brother 

I understand, but is there a way to store non sensitive data in automation rules?

And is there a way to reach an endpoint which uses OAuth authentication, using "Send Web Request" Action?

Thanks,

Venkat

[YY Brother]

[Darryl Lee]

Yep, Issue Properties, Project Properties, these are all fine places to store non-sensitive data.

But IF YOU ARE TEMPTED to put an OAuth token in there, you should be aware that any user who has view access on the issue or project, can view all associated properties via the REST API.

Examples:

https://YOURSITE.atlassian.net/rest/api/3/issue/BUG-6/properties

https://YOURSITE.atlassian.net/rest/api/3/project/BUG/properties

So again, you do not want to store anything like an Oauth token there, because it is definitely NOT protected.

[Venkat]

Hi @Darryl Lee 

Yes, I Agree as you said. Its not advisable to store sensitive values in entity properties.

As suggested by @YY Brother,  Fetching an Access access token every time is not suitable for my case as this automation will be triggered whenever a ticket's priority/status is updated (due to throttle limit)

But then, is there any other way to reach an endpoint which uses OAuth as authentication method through "Send Web Request"? Do you have any inbuilt OAuth Access token generation flow for Automations?

Regards,

Venkat

[YY Brother]

”Fetching an Access access token every time is not suitable for my case as this automation will be triggered whenever a ticket's priority/status is updated (due to throttle limit)“

Please detail your requirement so that we can assess if automation fits or not.

[Darryl Lee]

Doing some Googling, I found an interesting approach to this problem by @Brandon Davies , using Assets to manage and store the tokens.

• The Secure Way to Manage OAuth API requests in Jira Automation

The key is:

For security reasons, definitely remember to limit the access to the schema that this object resides in. You can access this by going to the Asset schema configuration and limit who can view the schema and edit it.

But I'm thinking, if you don't have Assets, what if you just created a very very small project called OAUTHKEYS to store the tokens, with access limited to you and other admins. If the automation runs as the Automation Account that also has access to that project, you could use it to store and rotate the tokens every 60-90 days or whatever works.

[Rick Westbrock]

See my answer linked below in another thread for how you can make a web request to send the OAuth credentials and access the returned token to use in the next web request action: 

https://community.atlassian.com/t5/Automation-questions/Re-Jira-Automation-how-to-send-a-webrequest-to-an-endpo/qaq-p/2728931/comment-id/10862#M10862

[Darryl Lee]

Hi @Rick Westbrock 

Yes, the {{webResponse}} smart value can be used in other web requests in the same rule.

But what @Venkat was asking for was a way to store an Oauth token so that it could be used in other rules.

That means storing it somewhere persistent, but also secure.

[Rick Westbrock]

Without seeing Venkat's automation rule my assumption was that they generated the token in some other fashion (such as Postman) instead of generating it with a web request action in the automation rule.

I should have explained that in most cases the token has a limited lifetime so eventually that stored token will no longer be valid and the rule will need to request a new token anyway.