Where Jira time trackers store your API token (and why it matters)

A Jira API token is a long string that grants permission to read and write your worklogs, browse your issues, comment on them, and — depending on your role — change a lot more. Atlassian’s own token management docs treat it as a personal credential: created from your account, scoped to your permissions, revocable from the same screen. Where it ends up after you paste it into a time tracker, though, varies enormously between products, and that difference is exactly the thing your IT or security team will care about during a vendor review.

I’m the co-founder of Planim Time, so the bias is up front. We built one of the trackers in this list specifically because we didn’t want our customers’ tokens sitting in our database. The goal of this post isn’t to tell you which choice is “right” — it’s to put the actual auth model each tracker uses on the table, so the trade-offs are visible. Some of them are genuinely fine. Some have failure modes that don’t surface until something else goes wrong.

The threat model, in one paragraph

A Jira API token is a bearer credential: anyone holding the cleartext can act as you against the Jira REST API. The interesting question for any tracker isn’t “is the token encrypted?” — it always is, in transit and at rest. The interesting question is who else holds the cleartext, and under what circumstances does it become reachable? A token in your OS keychain is reachable to processes running as you, on this machine. A token in a vendor’s cloud is reachable to that vendor’s infrastructure, their on-call engineers, anyone who breaches them, and any subpoena that lands on their doorstep. Both are defensible designs. They just have very different blast radii.

Three auth models in this category

Every Jira time tracker authenticates with Jira using one of three shapes:

1. Atlassian Connect / Forge. A Marketplace app that the Jira admin installs into your tenant. At install time, Jira and the vendor exchange an installation secret, and from then on the vendor authenticates to Jira via JWTs signed with that secret. The secret lives on both sides: in Atlassian’s tenant and in the vendor’s backend. The user never sees a token. (Atlassian stopped accepting new Connect submissions on the Marketplace in 2024; existing Connect apps still run, and vendors are migrating to Forge, which moves more of the runtime onto Atlassian’s infrastructure but keeps the basic shape.)

2. User-supplied API token, vendor-stored. The user generates a personal Atlassian API token, pastes it into a vendor signup form, and from then on the vendor uses it to call Jira on the user’s behalf. The token sits in the vendor’s database, encrypted at rest. Browser-extension trackers and most “connect your tools” SaaS dashboards work this way.

3. User-supplied API token, locally stored. The user pastes a token into a desktop app, and the app saves it to the OS credential vault — Keychain on macOS, Credential Manager on Windows, Secret Service on Linux. The vendor’s servers never see the token. This is rarer, partly because it forces a desktop-first product shape and partly because it makes growth-team-style sign-up flows harder.

Each model trades a different thing for a different thing. Connect/Forge centralises admin install and revoke through Jira itself but requires you to trust the vendor’s backend forever. Vendor-stored tokens are easy to set up but expand your blast radius. Locally-stored tokens are airtight against vendor breach but are per-machine by design.

Tempo Timesheets

Tempo Timesheets is a Marketplace plugin and uses Atlassian Connect for its Jira-side authentication: a Jira admin installs Tempo, Atlassian and Tempo exchange a shared secret, and the plugin authenticates with JWTs from then on. The user doesn’t paste anything to make the integration work.

Tempo also issues its own personal API tokens for Tempo’s REST APIs — these are separate from Jira tokens and only authenticate calls to Tempo, not to Jira. They’re shown once and stored on Tempo’s side. There’s a known administrative gap here: only the user who created a Tempo API key can view or revoke it, which becomes uncomfortable during offboarding. If a developer leaves and IT doesn’t think to ask them to revoke their Tempo key first, that key can outlive their employment. Tempo’s product team has acknowledged the request for centralised admin; check the linked idea for current status.

Where the cleartext lives: Atlassian’s tenant + Tempo’s backend (Connect secret). For Tempo API users: Tempo’s database (Tempo-side token).

Clockwork (HeroCoders)

Clockwork is also a Marketplace plugin built on Atlassian Connect, with the same shape as Tempo. HeroCoders is a Cloud Fortified vendor — Atlassian’s program that requires meeting their cloud security and reliability standards plus participation in Atlassian’s Marketplace Security Bug Bounty Program. For most Jira admins, “Cloud Fortified” is itself the answer to the security question — it’s a substantive certification, not a marketing badge.

Clockwork also publishes its own REST API with user-generated API tokens, used for scripting against Clockwork itself. Same shape as Tempo: tokens issued in Clockwork’s UI, stored in HeroCoders’ backend, scoped to that user’s Jira permissions.

Where the cleartext lives: Atlassian’s tenant + HeroCoders’ backend (Connect secret). For Clockwork API: HeroCoders’ database.

Everhour

Everhour is a hybrid: a Marketplace add-on that surfaces the timer inside Jira, plus an Everhour cloud account that holds your time data, projects, budgets, and integrations. The Jira side uses the Marketplace install path; the Everhour side requires you to log into Everhour itself. Your Everhour account is the system of record for hours; the Jira plugin authenticates through whatever the Marketplace install configured at admin time.

If you also use Everhour for non-Jira tools (GitHub, Trello, Asana, etc.), each of those integrations stores its credentials in your Everhour cloud account. None of those credentials live on your machine.

Where the cleartext lives: Atlassian’s tenant (Marketplace install) + Everhour’s backend (Everhour user creds and any non-Jira integration tokens).

Clockify

Clockify uses user-supplied API tokens stored in their cloud account. The Jira integration is configured through your Clockify account: you generate a Jira API token, paste it into Clockify, and from then on Clockify’s servers call Jira’s REST API on your behalf. Clockify is SOC 2 compliant and hosts EU customer data on Frankfurt servers, which is the right operational story — but it doesn’t change the structural fact that your Jira token is in their database.

Clockify’s own API uses an X-Api-Key HTTP header containing a key generated in your Clockify profile. That key authenticates against Clockify, not Jira; same storage location.

Where the cleartext lives: Clockify’s backend (Jira API token, Clockify API key, account credentials).

Planim Time

Planim Time is a native desktop app for macOS, Windows, and Linux. The Jira API token never leaves your machine. The implementation is small enough to print:

use keyring::Entry;

const SERVICE: &str = "planim-time-tracker";

pub fn set_secret(key: &str, value: &str) -> Result<(), String> {
    Entry::new(SERVICE, key)
        .map_err(|e| format!("Keyring entry error: {e}"))?
        .set_password(value)
        .map_err(|e| format!("Failed to save to keyring: {e}"))
}

pub fn get_secret(key: &str) -> Result<Option<String>, String> {
    match Entry::new(SERVICE, key)
        .map_err(|e| format!("Keyring entry error: {e}"))?
        .get_password()
    {
        Ok(v) => Ok(Some(v)),
        Err(keyring::Error::NoEntry) => Ok(None),
        Err(e) => Err(format!("Failed to read from keyring: {e}")),
    }
}

That’s the entire storage layer. The keyring crate wraps three platform APIs:

• macOS — Keychain Services, the same vault Safari uses for saved passwords
• Windows — Credential Manager, accessed via the Win32 Credential Vault APIs
• Linux — Secret Service over D-Bus, which is what GNOME Keyring and KWallet implement

Our backend never sees the token. The desktop app talks directly to your Jira instance over HTTPS using the token from the keychain; the only thing that flows through our servers is your Planim Time license check, which is a separate credential. If we got breached tomorrow, the token in your keychain is unaffected. If you uninstall the app, the token can be inspected or deleted from the keychain directly — for example, on macOS:

security find-generic-password -s planim-time-tracker
security delete-generic-password -s planim-time-tracker

I wrote a longer technical post on the implementation if you want the rationale at code-review depth.

Where the cleartext lives: the OS keychain on your machine. That’s it.

Quick comparison

What your IT team should ask

When the security review form lands on someone’s desk, the questions worth asking are concrete, not generic:

• Where, exactly, is the cleartext credential stored? “Encrypted at rest” is necessary but not interesting; you want a name (vendor backend / Atlassian tenant / OS keychain).
• Who can revoke it without involving the user? A token only the original user can revoke is a problem at offboarding.
• What happens if the vendor is breached? Map your token’s blast radius the same way you’d map any other credential.
• Does the vendor decrypt the token in the request lifecycle? Some vendors decrypt server-side to make the API call; others act as opaque proxies. The first model means cleartext is reachable to vendor on-call engineers.
• Is the integration Cloud Fortified or Forge-published? For Marketplace plugins this is the closest thing to a default certification.

What we ended up choosing, and why

Picking the OS keychain meant accepting a few constraints up front. Tokens are per-machine, so if you use the tracker on a laptop and a desktop, you paste twice. There’s no admin-side “revoke a token across all your team’s installs” panel, because the tokens never reach our backend in the first place. Onboarding can’t auto-detect a Jira workspace from your email domain, because we don’t have your credentials.

What we got back: our breach surface for Jira tokens is exactly zero. The token is in your vault, on your hardware. Our logs don’t have it, our backups don’t have it, our dev environment doesn’t have it. For teams whose security review explicitly asks “does the vendor store our Jira credentials?” the answer is no, and there’s nothing to qualify.

That trade-off only makes sense for a desktop-first product. If we’d built a web dashboard, we couldn’t have made it; the auth model and the product shape are the same decision. We wrote separately about why we shipped a desktop binary instead of a Marketplace plugin; this is the half of the rationale that lives in your security questionnaire.

If the storage side of this matters to your team, download Planim Time, point it at a real Jira instance, and check Keychain Access on macOS (or wincred on Windows, or seahorse on Linux) — you’ll see the token entry sitting in your vault under planim-time-tracker. That’s the whole story.