The use case
We built a Forge app that grants issue-level read access based on user fields of a source issue. In a Jira Software project, an access grant is worthless without product access — so the app must add and remove users from a licensing group (a group that grants jira-software access). Fully automated, unattended, and ideally without any credential that expires and needs rotation.
This is not exotic: any app that provisions access, syncs teams, or mirrors an external source of truth into Jira groups hits the same wall.
What we tested (all verified on Jira Cloud, Aug 2026)
| Approach | Result |
|---|---|
Forge asApp with write:group:jira + read:group:jira + manage:jira-configuration → POST/DELETE /rest/api/3/group/user |
403 forbidden — no Forge scope grants site-admin-level group management |
| Adding the Forge app account to an admin-capable group | 400 UserModificationNotAllowed — app accounts cannot be added to any group |
Native service account (Atlassian Guard) with OAuth 2.0 client_credentials, JWT scope claim contains exactly read/write/delete:group:jira → /ex/jira/{cloudId}/rest/api/3/group/user |
401 scope does not match — 2LO is rejected for endpoints requiring ADMIN, regardless of granted scopes |
Same service account credential with manage:org → org admin API /admin/v1/orgs/{orgId}/directory/groups/{groupId}/memberships |
401 Unauthorized |
Same service account credential with manage:org → org admin API /admin/v1/orgs/{orgId}/directory/groups/{groupId}/memberships |
401 Unauthorized |
| Org API key (bearer) or admin user API token (basic auth) | Works — but both expire and require rotating an admin-level secret for a background job, which is exactly what client_credentials exists to avoid |
One measurement pitfall worth sharing: a DELETE /group/user for a non-member returns 400 "user is not a member", which looks like the authorization step passed. It didn’t — the membership check runs before the permission check. Always verify with an actual member.
Atlassian’s confirmation (Ecosystem Support, Aug 2026)
- No Forge scope covers group management. The endpoints require site-admin permissions;
manage:jira-configurationputs the app bot intoatlassian-addons-admin, which is restricted to configuration management. - App accounts cannot be elevated — deliberate design boundary, so that scopes remain the sole privilege mechanism.
- OAuth 2.0 (2LO) is blocked for admin-level endpoints even when the scopes are granted and present in the token.
- No no-code alternative exists: product access is driven by SCIM/IdP or by admin-authenticated action only — nothing can derive it from data a Forge app is allowed to write (project roles, custom fields).
What we’re asking Atlassian for
A supported, non-expiring, least-privilege credential path for automated group membership management — any of these would solve it:
- an admin-capable scope for service account
client_credentials(group membership only, not full site-admin), or - a Forge scope / permission that allows an app to manage membership of explicitly designated groups (opt-in per group by an org admin), or
- a provisioning rule in admin.atlassian.com that derives product access from something an app can write (e.g. a project role).
The opt-in-per-group variant would keep the security model intact: an org admin explicitly delegates specific groups to specific apps — far safer than what everyone does today instead, which is embedding rotating org-admin secrets into background jobs.
Vote
- Feature request: ECO-1713 ← please watch and vote
- Related: AX-1603 (service account impersonation for OAuth 2.0), CONFCLOUD-83962 (admin key support for OAuth 2.0)
- Earlier unanswered report of the same 403: Forge App: 403 Forbidden with manage:jira-configuration Scope for Group Management
Has anyone found a supported workaround we missed — or do you have the same requirement? Reply here so the demand is visible in one place.