What is the best practice to store 3rd party token using Atlassian connect?

I am creating an Atlassian Connect with WebPanel module. I would like to do the below things, Is it possible? I attached the sequence diagram.

Use story:

  • Users use OAuth token which is generated by my service, to communicate with my service.
  • If one user has gotten the token already, other users do not have to get the token again. They can share the token to communicate with my service so I need to store the token to Add-on or Jira?

Sequence diagram:

Thanks in advance.

If any user at all on the instance is allowed to access the token, have you considered app properties? https://developer.atlassian.com/cloud/jira/platform/storing-data-without-a-database/

1 Like

@rmassaioli I appreciate your response but it is not good idea because I think we should not store sensitive data such as token to App Properties according to Storing data without a database.

App properties can be manipulated by a malicious authenticated user (e.g., by making REST calls through the developer console). For this reason:

  • Don’t store user-specific data in app properties (particularly sensitive data).

Please correct me if I am wrong.

I think that the real question is:

  • If a user of that tenant got their hands directly on the token, would that be a security issue for your app?
  • If a user modified the value for the token, maybe setting it to some other token, would that be a security issue for your app?

If the answer is NO to both, then App properties should be fine for your use case. If it is Yes to either, then you’ll likely need to store the token in your backend service and call to it using another auth mechanism.



Sorry not to replay quickly. I was OOO.
I appreciate you summarize my question. There are exactly I would like to ask.

In my situation, both answer is NO so I will store the credential data in my backend.
First one is YES so I will store the credential data in my backend

Thanks again :smile:

I’m confused. You said the answer to both was no but suggested to store in your back-end anyway.

1 Like

@rmassaioli Sorry I misunderstood. I edited my previous response.