Is it possible to impersonate another user via Jira Cloud API using a service account or any other mechanism?

General
, , , ,
1

I’m trying to understand if it’s possible to perform actions in Jira Cloud on behalf of another user via APIs, using a backend service or service account.

The use case is to run automated operations (e.g., creating issues, exports, updates) while attributing the action to a specific user and respecting their permissions.

I haven’t implemented a specific approach yet, but I’m exploring options such as Forge Remote with offlineUserAuthToken flow.

Questions:

  1. Is user impersonation supported in Jira Cloud APIs?

  2. Can a service account be used to impersonate another user?

  3. If not, what is the recommended approach to perform actions “on behalf of” a user from a backend service?

  4. How can we ensure that the actions respect the target user’s permissions and are properly audited?

Looking for guidance on the correct pattern or supported approach for this use case.

2

Welcome to the Atlassian developer community @TammaliDeepak,

No and yes. The APIs do not support user impersonation for all access methods. Forge allows for “offline user impersonation” through api.asUser(userId).requestJira()

No.

Forge Remote using offline user impersonation.

Using offline-user-impersonation does not circumvent permissions or auditing, so I’m not sure there is anything your app would need to do. Did you have a specific concern from your research on Forge & Forge Remote thus far?

3

Thanks @ibuchanan , that helps.

Just to clarify my situation — my main goal is user impersonation from a backend service (e.g., creating/updating issues as a specific user while respecting their permissions).

I understand that Forge (offline user impersonation) can enable this, but I’m not really trying to build a Forge app as the end product for this use case. It would be more of a bridge to allow my backend to execute actions in a user context.

Given that, I wanted to check:

  • Is Forge (with offline user impersonation) effectively the only supported way to achieve this in Jira Cloud?

  • Is using Forge in this kind of “bridge” role an intended/supported pattern?

  • Are there any limitations or concerns with this approach (e.g., auth flow, consent, scaling)?

Just want to make sure I’m aligning with the recommended approach and not forcing Forge into something unintended.

Appreciate the guidance.