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.

4

@TammaliDeepak,

Yes.

No and yes. No, in the sense that Forge Remote was not intended to bridge from the remote side into Atlassian. Yes, because the token’s TTL has been extended to 4 hours and can be used with a scheduledTrigger to make sure there is always a fresh token. See:

https://community.developer.atlassian.com/t/forge-remote-access-to-tokens-anytime-is-now-in-preview/

I guess my dual answer is meant to express:

  • I understand why this doesn’t look like the right thing. For your scenario, you would expect your service to initiate the flow.
  • That said, Forge Remote is the closest thing we have to that. It’s what I have recommended in my work with SaaS partners.

I’m not aware of any open suggestions or defects that indicate limitations or concerns.

5

Thanks @ibuchanan for taking time to respond, that clarifies things - makes sense that Forge Remote is the closest supported approach here.

On our side, we’re authenticating into Jira Cloud using Microsoft Entra ID as the upstream IdP.

Given that, is there any way to leverage that setup to perform actions on behalf of users without going through Atlassian Forge (offline user impersonation)?

Or would we still need to rely on Forge for this regardless?

Just checking in case you’ve come across anything along these lines in the past.

thanks again.

6

No leverage. It’s still Forge.