Best practice for authentication to Jira Cloud for long-lived automations and integrations?

[Corinne Guibert]

Hello,

Our company has many integrations with our Jira instance. It can be:

* Python script

* WebService call from Jira Automation

* Java code

In most cases, authentication is done using an API token associated with a user account.

The problem is that API tokens expire after one year. Every year, I would have to:

• generate new API tokens,
• update the configuration of all our scripts and automations,
• make sure nothing is missed.

This also creates an operational risk since it's linked to a user account (people in vacation or  leaving the company): if a token expires, several automations and integrations may stop working until someone updates the credentials.

Is there a better (long term) way to achieve this kind of integration ?

Thanks for your feedbacks

[Mikael Sandberg]

You could use a service account for this, that way you do not rely on individual users. Service accounts do not count towards your license count and you get up to 5 accounts that you can configure the access for. Have a look at this KB article for more information.

[Jason Krewson]

Service accounts are great for this. You can also set up calendar reminders for your team a week or two out before the API token expiration dates so you can get them updated prior to expiration. 

[Mikael Sandberg]

There is also a suggestion to add a secret store, AUTO-1365, for automation so that you only have to go to one place and update the token. Please vote and follow if you would like to see this implemented. 

[Gor Greyan]

Hi @Corinne Guibert

For this use case, I would separate the options into two patterns.

If these are internal scripts or server-to-server integrations, the most practical approach is usually a dedicated service account, not a personal user account. The API token will still need rotation, but it avoids the risk of the integration being tied to an employee account, and you can manage the token centrally.

If you are building a proper custom application or integration, then OAuth 2.0 (3LO) is a better long-term option. With OAuth, you do not manually recreate a yearly API token in the same way. The app receives short-lived access tokens and can use refresh tokens to continue access, assuming the user has granted consent and the authorization has not been revoked. Atlassian documents this flow here.

https://developer.atlassian.com/cloud/oauth/getting-started/implementing-oauth-3lo/
https://developer.atlassian.com/cloud/oauth/getting-started/refresh-tokens/

[Gabriela]

Hi @Corinne Guibert, this is what service accounts are built for. Move these integrations off personal accounts onto a service account in admin.atlassian.com under Directory > Service accounts. There's no person attached, so nobody's vacation or departure can break a script, and it doesn't consume a Jira or Confluence seat.

You then generate credentials for it. For the Python and Java code, create an OAuth 2.0 credential (Actions > Create credential), which gives you a client id and secret. POST those to https://auth.atlassian.com/oauth/token with grant_type=client_credentials and call the Jira Cloud REST API with the short-lived bearer token it returns. That's the clean server-to-server route and it takes the yearly user-token churn off your plate. For the Jira Automation 'Send web request', a scoped API token on the same service account is simplest — drop it into a hidden Authorization header as Basic base64(email:token), since the rule runs as its actor.

Either way, plan for rotation. API tokens now cap at a one-year expiry, so bake renewal into the setup if you stay on tokens rather than moving to OAuth.

Atlassian's docs cover both — understand service accounts (https://support.atlassian.com/user-management/docs/understand-service-accounts/) and creating an OAuth 2.0 credential (https://support.atlassian.com/user-management/docs/create-oauth-2-0-credential-for-service-accounts/).

Best, Gabriela