Jira Cloud REST API Integrations: Is a Dedicated Service Account Still the Recommended Approach?

July 20, 2026

Hi Community,

I'm looking for guidance on REST API authentication best practices for Jira Cloud integrations.

I understand that using a personal user account and API token for integrations is generally not recommended due to ownership, audit, and continuity concerns.

In our environment, many clients are not using CI/CD pipelines, OAuth apps, or more advanced integration frameworks. As a result, the simplest approach has been to create either:

A dedicated service account for integrations, or
A dedicated group/API user account with the required permissions

and then generate a separate API token specifically for the integration.

My questions are:

Is a dedicated service account with its own API token still considered a recommended approach for Jira Cloud integrations?
How are other organizations handling third-party integrations such as Qualys, Sumo Logic, SIEM platforms, or custom applications?
Are there any governance or security concerns with maintaining dedicated integration accounts and API tokens?
Has anyone moved from API-token-based authentication to a more modern approach, and if so, what benefits did you see?
What does Atlassian currently recommend for customers who need a practical solution but are not using development pipelines or custom OAuth implementations?

I'd appreciate hearing how others are managing this in real-world Jira Cloud environments.

Thanks in advance!

Sonal

11 comments

Ever since they released Service Accounts for cloud, this has been my go-to unless certain requirements justify otherwise. Some advantages include not having to burn extra licenses and being able to control token expirations, renewals, and scope parameters. To many times I've seen tokens expire or not being scoped correctly resulting in avoidable headaches.

Something to note. Certain data points can be omitted from api end points even if they are listed as part of the JSON structure. For example, worklogs show users email as a data point but it will be omitted from the actual GET payload. So make sure you account for these type of things for short and long term use.

Like • like this

I would always use a service account where you can, API keys expire and need to be renewed every 365 days, whereas service accounts are ongoing, sure theres an extra process you need to implement to get an auth code but atleast you will be building a process that will continue to operate beyond when you leave the organisation.

Like • like this

Hi @Sonal Malik , great question. I agree with what Devlend and Luke have already said: ever since service accounts appeared, they've been my favorite option too. You save licenses, you gain control over token expiration, and above all you keep user accounts as what they are —user accounts— without mixing them up with integrations. It's true you have to implement an extra step in the authorization, but it's worth it. Here's my take on each point:

Is a dedicated service account with its own token still recommended? Yes, it's still the most practical approach and the one I'd recommend by default. It's exactly the use case Atlassian designed service accounts for: decoupling the integration from any specific person. One detail to keep in mind: service accounts can only create scoped tokens, and these don't work against your site URL (yourdomain.atlassian.net) but rather through the gateway api.atlassian.com/ex/jira/{cloudId}/.... Worth bearing in mind when setting up the integration.
How are other organizations handling third-party integrations (Qualys, Sumo Logic, SIEM…)? Ideally, a dedicated service account per integration, not one shared across all of them. That way you isolate permissions, and if you need to revoke or rotate a token for one tool, you don't bring down the rest. It's useful to place each account in a dedicated group (e.g. jira-connector-svc) and manage permissions through that group, which makes auditing and offboarding much simpler. For tools that support OAuth 2.0, OAuth is better than a token.
Any governance or security concerns? The main ones: apply least privilege (choose only the scopes the script actually needs), maintain an inventory of which account is used by which integration and who owns it, rotate tokens regularly, and don't reuse the same token across multiple integrations. Keep in mind that tokens expire after 365 days at most (one year by default for those created after December 15, 2024), so you have to plan for renewal. The advantage of the service account is precisely that ownership and auditing don't depend on an employee still being with the company.
Has anyone migrated to something more modern, and what benefits have they seen? Migrating to OAuth 2.0 brings granular scopes and short-lived tokens with rotating refresh (the refresh token renews and is valid for 90 days), which reduces the exposure window if something is compromised, and avoids having to manually manage the annual expiration. In exchange, it requires more initial setup, so it pays off mostly for critical or long-lived integrations.
What does Atlassian recommend for those not using pipelines or OAuth? The pragmatic approach you're already following: a dedicated service account + a scoped token with minimum permissions, managed via a group. It's the supported and straightforward path for that client profile. Only in very specific cases would I resort to a token on a user account: when the actions being performed are actually carried out by that person.

In short: service account as the default option, and OAuth when the tool allows it and the case justifies it. As always, it's worth double-checking the details (expirations, limits, endpoints) against the latest official Atlassian documentation, since these policies keep getting updated.

Reference — Atlassian documentation:

Manage API tokens for service accounts: https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/
Manage API tokens for your Atlassian account: https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/
OAuth 2.0 (3LO) apps – Jira Cloud platform: https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/

Like • like this

Hi @Esther Ortega ,

Thank you for the detailed insights and recommendations. The governance, auditing, and continuity benefits of using dedicated service accounts certainly make a strong case for them as the default approach.

One challenge I've encountered in practice is determining the appropriate permissions and scopes when creating a service account. There are often a large number of available options, and it is not always clear which permissions are actually required by a specific integration. While I fully support the principle of least privilege, finding the right balance between functionality and security can be difficult, especially when configuring integrations such as vulnerability management, SIEM, or other third-party platforms.

In my current environment, I typically start with the minimum permissions I believe are necessary and then adjust based on integration requirements and testing results. However, I'm curious to know whether others have established best practices for identifying the correct project permissions, groups, and API token scopes upfront, rather than relying on trial and error.

Thanks again for sharing your experience and the documentation references. This has been very helpful and has given me additional considerations for how we manage integration accounts going forward.

Regards,
Sonal

Like • like this

Thanks, @Luke Gackle. I agree that tying integrations to an individual user account creates long-term ownership and continuity risks, especially when staff change roles or leave the organization. One challenge I've encountered with service accounts is determining the appropriate permissions and token scopes. In many real-world integrations, there are numerous options available, and it isn't always obvious which permissions are actually required. My goal is to follow the principle of least privilege, but identifying the right combination of project permissions, group memberships, and API scopes can be difficult without extensive testing. Have you found a good approach for determining the minimum required permissions upfront, or do you typically start with a limited set of permissions and then expand based on integration requirements and testing results?

Thanks again for sharing your perspective. The long-term sustainability and governance benefits of service accounts definitely seem worth the additional setup effort.

Thanks, @Devlend Maul. The ability to use service accounts without consuming additional licenses, while also having better control over token management and scope assignments, is definitely a strong advantage. I've seen similar challenges with token expiration and permissions, and having a dedicated integration account helps simplify governance and ownership.

One area I still find challenging is determining the appropriate scopes and permissions when setting up a service account. There are often many available options, and it isn't always clear which ones are truly required for a given integration. While I try to follow the principle of least privilege, it can take some testing to identify the minimum set of permissions needed without impacting functionality.

I also appreciate the point about API responses not always containing all documented fields. That's a valuable reminder, especially when designing integrations that may rely on specific user attributes or metadata. Accounting for those limitations early can certainly help avoid issues in both initial implementation and long-term maintenance.

Thanks for sharing your experience. It's helpful to hear how others are approaching service accounts and integration governance in Jira Cloud.

@Sonal Malik Some of it is trial and error to be honest, Atlassian have structured some of their products terribly, for instance I hate how JSM Operations is a totally seperate part of jira, going into alerts re-directs you to a totally different interface with different UI and navigation, and due to its seperation it also has totally different API scopes that are required to interface with it, Atlassian support has been pretty helpful in this regard though wherever there was confusion on what scope was required for a particular API endpoint.

Thanks for replying, @Sonal Malik ! I have exactly the same experience: identifying the scopes in advance is really tricky, especially if you want to fine-tune to least privilege rather than falling back on the broader "classic" scopes.

After digging a bit, I've confirmed that the "official" approach Atlassian proposes is to go operation by operation. On the OAuth 2.0 (3LO) apps page there's a section titled "Determining the scopes required for an operation" that states it literally:

"To find out which scopes an operation requires, check the OAuth scopes required field in the relevant API documentation."

In other words, each endpoint in the REST API reference includes an "OAuth scopes required" field with the scope it needs, and the idea is to list all the operations your integration uses and build the list from there. A couple of caveats from that same page worth keeping in mind: if the operation says "Apps can't access this REST resource" it can't be used with OAuth 2.0 (3LO); and even if the token has the scope, the permissions of the user the app is acting on behalf of still rule (if the user doesn't have the permission in Jira, the scope isn't enough).

There's also the distinction between classic scopes (broader, e.g. read:jira-work, write:jira-work) and granular ones (more specific, e.g. read:issue-details:jira, read:jql:jira); Atlassian recommends using the classic ones unless you really need to narrow things down.

Here are the reference links:

"Determining the scopes required for an operation" section: https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/
Jira platform REST API reference (each endpoint shows "OAuth scopes required"): https://developer.atlassian.com/cloud/jira/platform/rest/v3/
List of Jira scopes: https://developer.atlassian.com/cloud/jira/platform/scopes-for-oauth-2-3LO-and-forge-apps/

Even so, I still feel there's no "automatic," quick way to extract them: it remains fairly manual. If anyone in the community has found a more agile way to identify them clearly (some tool or trick), I'd be delighted to hear it too.

Best regards!

Esther

Thanks, @Luke Gackle , That makes sense. I've run into a few cases already where the documentation wasn't completely clear, so it's good to know some trial and error is expected. The separate JSM Operations scopes are especially helpful to know about in advance. Appreciate the insight!

Thanks, @Esther Ortega . This is very helpful and confirms what I've been seeing during testing. It does seem that identifying scopes remains a fairly manual process, particularly when aiming for least-privilege access. I appreciate you sharing the documentation links and additional considerations around classic vs. granular scopes. Thanks for the insight!

@Sonal Malik

Below are links to some Atlassian developer documentation on API Scopes which include definitions. They should be the same if your creating OAuth 2.0 for Service account.

Jira API Scopes: https://developer.atlassian.com/cloud/jira/platform/scopes-for-oauth-2-3LO-and-forge-apps/

Confluence API Scopes: https://developer.atlassian.com/cloud/confluence/scopes-for-oauth-2-3LO-and-forge-apps/