Is this OK for an external Jira integration to store API tokens? If so, where and how?

We are working on an integration that would rely on authenticating with Jira API tokens. The idea is that first time when it is necessary, we want to ask the user to enter his API token to our web form.

The question is: is this OK to store and re-use the API token for further interactions? (Asking for that again and again would lead to annoying user experience.)

The security requirements for cloud apps page have a vague sentence related to this:

  1. The application must not collect Atlassian user credentials.

What does “collect” mean here? If you can’t save the token to an automation script, e.g., then what’s the point of the tokens at all? Or does it mean that you cannot ask and store API tokens for a large number of users?

Of course, storing those is a security concern, but we could imagine something along these lines:

  1. Storing these as encrypted user properties. We can use JWT to access the “get user property” and “set user property” end-points, obtain the API token from there and use that. In other words, we would “outsource” the problem to Jira Cloud.

  2. Storing these as passwords in the browser’s own password manager. I am not 100% sure if it is doable, but it is, it will be just as secure as your Jira password. In other words, we would “outsource” the problem to the browser (Google, Microsoft, etc.).

  3. etc.

Anyone did anything like this before?

I’m pretty convinced credentials in this case actually stands for username & password. I’m not sure tokens do actually fall under that. I mean, tokens are specifically designed to be used by apps / third parties, right?

I would strongly oppose against the two ideas you mentioned. The idea behind auth tokens is kind of that they are used by the backend of your app. They should never reach the frontend (and therefore should not be stored in properties or Browsers).

I interpret this requirement to mean something along the lines of: “Don’t try to collect user credentials so you can hack yourself a way into using APIs that Atlassian didn’t specifically greenlight for apps”. (And generally you just wouldn’t want to store user credentials anyway for many other reasons, right?)

Are you sure you need API tokens? If you’re going to ask the user, why not go for 3LO?

API tokens should be used for non-interactive tasks (like CI/CD). If you can interact with the user, it is always preferred to use OAuth.

Of course, you’re right. API tokens are somewhat counter-intuitive to be used this way.

If there was another easy way, I’d do that. Currently, we are in a situation which can be solved only this way, so my options are “not solve the problem at all” or “solve the problem in a counter-intuitive, hacky way”.

@remie Yes, 3LO could be (is) an option, but it bring much more complexity than API token. We will see.