[Episode 7] The API token that quietly became “everyone’s problem”

[#1]

Hello Everyone!

Back with a small discovery that’s worth sharing.

If you’ve been around Jira/Confluence Cloud long enough, you’ve probably seen this happen: a small automation starts as a “quick fix” (pull a report, sync a field, create issues from a form), someone generates an API token, and life is good. Then the automation becomes important. Then more automations show up. Then multiple teams start depending on the same REST API access… and suddenly that one token is powering half your workflows.

That’s when Cloud REST APIs stop being “just integrations” and start becoming infrastructure.

Atlassian Cloud REST APIs are everywhere because they’re the simplest way to connect your Atlassian data with the tools teams already use: CI/CD, HR systems, reporting pipelines, partner portals, and internal apps. And the more you rely on them, the more the authentication model matters.

Here’s the good news: Atlassian has been making it easier to do machine-to-machine access properly in Cloud, without tying critical automations to a person.

In Atlassian Cloud, you can create service accounts, non-human identities intended for scripts, integrations, and automations[ref]. For each organization, Atlassian allows up to five service accounts for free (and points to Atlassian Guard if you need more).

Once you have a service account, you can generate credentials for it, like API tokens with scopes, and you can manage and monitor those tokens (created, expiry, last used) from a central place in the administration panel. Alongside API tokens, you can also set up OAuth 2.0 credentials to obtain access tokens for REST API calls.[ref]

Why this matters in real life is pretty simple:

• When the “integration identity” is a person, the automation’s future depends on that person’s account lifecycle.
  
  
• When the identity is a service account, ownership becomes cleaner, rotation becomes safer, and audits become less awkward because the automation has a name that matches what it does. [ref]
  
  

And once you start doing more than one integration, the pattern becomes even more valuable: instead of one token powering everything, you can move toward one service identity per integration (or per team/system). If a token rotates for one workflow, it doesn’t knock over the rest. If one integration gets paused, nothing else needs to be touched.

Quick note, because it comes up a lot: Atlassian also supports OAuth 2.0 (3LO) for apps that need to access APIs on behalf of a user. That’s great for user-context integrations. But for pure machine-to-machine automation, service accounts + scoped credentials are often the more straightforward fit. [ref]

If you’re using Cloud REST APIs today, here’s a simple question worth asking yourself: “If this token expires tonight, who wakes up tomorrow?”

If the answer is “too many people,” service accounts are one of the cleanest ways to bring calm back, without changing what your automations actually do.

Would love to hear how others are handling this: are your automations still tied to person-owned tokens, or have you started moving them to service accounts and per-integration identities?

Also, if you have anything specific, integration, or a way of solving this, do comment. Let's make this post even more informational! 

[s_gridnevskii]

We would not need many service accounts if token defines access, e.g. has a role in a Jira project/space or is added to a confluence space instead of an account itself. 

E.g. Jira admin can create a service account with 5 tokens - one for project A, another for project B and so on. Project administrator then adds the service account to project and Jira automatically applies access rights to the service account for specific project based on the token used.

This way we can give a temporary token to someone who needs e.g. create a report for auditors and generate permanent token for integration with internal services.

Using several service accounts is overkill if we just need one account but with different permissions in different spaces.

Another proposal could be to link service account to the user who requested the token so that this user gets notified when token expires. We have this in automation rules - owner and actor. Owner is informed when rule fails.

[Arkadiusz Wroblewski]

100% agree with this, the “one token that quietly becomes everyone’s problem” is probably one of the most common Cloud integration anti-patterns I’ve seen.

It always starts innocent: one script, one token, one person “just to get it working”. Then it becomes business-critical, gets copied into a second automation, then a third… and before you know it you have production workflows tied to a single human identity and a credential nobody wants to touch.

A few practical things that helped us get out of that trap:

1) Treat API access like infrastructure, not a shortcut
If it runs daily / touches lots of issues / supports a business process, it’s not “just an integration” anymore. It needs an owner, documentation, and a rotation plan.

2) One identity per integration (or per team/system)
The biggest mistake is one token powering everything. We try to align it like:

one service identity per integration/system (CI, reporting, HR sync, etc.)
That way if we rotate or pause one credential, we don’t knock over unrelated workflows.

3) Basic inventory (boring, but lifesaving)
We keep a simple register with:

what the automation does

where it runs (tool/repo/job)

which site(s) it hits

what permissions it has

who owns it

how/when the token is rotated
This alone reduces the “nobody knows where this token is used” problem by a lot.

4) Make token rotation normal, not a panic event
Rotation shouldn’t happen only when someone leaves. If rotation is easy and expected, the org stops being scared to touch it.

5) Pick the right auth model for the job
If the integration truly needs to act “as the user” (user context), OAuth makes sense.
If it’s machine-to-machine, tying it to a real employee account is asking for trouble even if it feels faster in the moment.

And your closing line is perfect:

“If this token expires tonight, who wakes up tomorrow?”
That’s the best litmus test I’ve heard in a while.

[Ananjan_miniOrange]

@s_gridnevskii 

Totally fair point, I like that model too.

What you’re describing is token-scoped access (one service account, multiple tokens, each token limited to a project/space/role) instead of identity-scoped access. Today, in most Atlassian Cloud setups, permissions are still enforced mainly at the account level, so tokens don’t act as separate permission boundaries, which is why teams sometimes end up using multiple service accounts for clean isolation.

Also +1 on token expiry notifications. That would make governance much smoother.

Just curious: if Atlassian added true project/space-scoped tokens, would you personally switch to one service account with multiple tokens, or would you still prefer separate service accounts for critical integrations? [ref]

[Ananjan_miniOrange]

@Arkadiusz Wroblewski 

Thanks so much and honestly this is such a solid add 🙌

I especially love the “inventory (boring, but lifesaving)” point… that’s exactly the thing most teams skip until something breaks. Also +1 to making rotation a normal routine instead of a panic event.

[s_gridnevskii]

@Ananjan_miniOrange yes, it would be very convenient to add the same service account to all projects and have different tokens for each project. This way a user who has a token will be able to access only one project and not others.

It will even be not too hard to implement from my point of view. Imagine user is an owner of a service account token and an administrator of Project A. He will be able to add this service account to his project and token will get permissions to this project only, not others that user does not have access to.