How service accounts work in Data Center

This page explains how REST API calls using OAuth 2.0 client credentials (2LO) authorization work in Data Center products, with a focus on scopes and permission handling.

How service accounts work in Jira Data Center

Scopes supported in Jira

Jira currently supports the following scopes for service accounts:

• READ – allows access to endpoints marked as READ.

• WRITE – includes WRITE endpoints, and also inherits READ access.

Endpoints requiring ADMIN, SYSTEM_ADMIN, or PROJECT_ADMIN privileges are not available through OAuth 2.0 calls.

The first layer of security is scope verification at the endpoint level. This mechanism is consistent across all Atlassian products.

For more information, see Jira OAuth 2.0 provider API documentation.

Endpoints available with OAuth 2.0 (client credentials)

• A complete list of supported endpoints can be found in the Swagger JSON specification.

• The security section of the spec now includes details about OAuth 2.0 scopes.

• In the initial release, only endpoints starting with /rest/api/2/ are exposed.

Permission system for service accounts

The second layer of security is Jira’s permission system, which defines how access is granted to projects, issues, and other resources.

Normally, permissions in Jira are assigned to groups, roles, or specific users. Service accounts differ because they are not standard Jira principals – they can’t be added to groups or configured in permission schemes.

As a result, permission checks for OAuth 2.0 calls behave differently:

• Admin permissions
  If the required permission is ADMIN, SYSTEM_ADMIN, or PROJECT_ADMIN, the request is automatically rejected.

• Non-project actions
  If the action does not involve a project entity (e.g., it is unrelated to a project, issue, or comment), the request is granted.

• Project-related actions
  If the action involves a project entity, Jira checks entity-level restrictions:

  • If no restrictions are configured, access is granted.

  • If restrictions exist, access is granted only when the project matches the allowed list.

A useful way to understand service accounts is: A service account acts like it belongs to every group, is every user, and has every role - except for admin roles, which are always denied.

How service accounts work in Confluence Data Center

Supported scopes

Confluence currently supports the following scopes for service accounts:

Endpoints requiring ADMIN, SYSTEM_ADMIN, or PROJECT_ADMIN privileges are not available through OAuth 2.0 calls.

The first layer of security is scope verification at the endpoint level. This mechanism is consistent across all Atlassian products.

For more information, see Linking to another application.

Endpoints accessible with service accounts

Service accounts can be used to access all non-admin Confluence REST API endpoints listed on Confluence Data Center REST API.

Permission system for service accounts

The second layer of security is Confluence’s permission system, which defines how access is granted to spaces and their content.

Normally, permissions in Confluence are assigned to groups, roles, or specific users. Service accounts differ because they aren't standard principals – they can’t be added to groups or configured in permission schemes.

As a result, permission checks for OAuth 2.0 calls behave differently:

• Admin permissions
  If the required permission is ADMIN or SYSTEM_ADMIN, the request is automatically rejected.

• Non-admin actions
  If the action involves an entity (like space, page, comment, etc), Confluence checks entity-level restrictions:

  • If no restrictions are configured for the service account, access is granted.

  • If the service account’s access is restricted to specific Confluence spaces, then we first determine the space in which the entity exists. Access is granted to the entity only when the space matches the allowed list for that service account.

A useful way to understand service accounts is: A service account acts like it belongs to every group, is every user, and has every role - except for admin roles, which are always denied.

How service accounts work in Bamboo Data Center

Endpoints available with Service Accounts

• A complete list of supported endpoints can be found in the Swagger JSON specification.

• The security section of the spec now includes details about OAuth 2.0 scopes.

Scopes supported in Bamboo

Bamboo currently supports the following scopes for service accounts:

• READ – allows access to endpoints marked as READ.

• TRIGGER - allows access to endpoints marked as TRIGGER and also inherits READ access

• WRITE – includes WRITE endpoints, and also inherits READ access.

Endpoints requiring Bamboo Administrator or Restricted Administrator privileges are not available through the 2LO OAuth 2.0 calls. Actions requiring Project, Deployment Project or Repository Administrator privileges are available to the Service Accounts.

Security

The first layer of security is scope verification at the endpoint level. This mechanism is consistent across all Atlassian products.

For more information, see Bamboo Auth 2.0 provider API documentation.

Permission system for service accounts

The second layer of security is Bamboo’s permission system, which defines how access is granted to plans, deployment project, and other resource.

Normally, permissions in Bamboo are assigned to groups or specific users. Service accounts differ because they are not standard Bamboo principals – they can’t be added to groups or configured in permission schemes.

As a result, permission checks for Service Account calls behave differently:

• Admin permissions
  If the required permission is a ADMINISTRATION, RESTRICTEDADMINISTRATION or SOX_COMPLIANCE on the Bamboo server instance, the request is rejected

• Non-project actions
  If the action does not involve a project, deployment project or repository, the request is granted.

• Project-related actions
  If the action involves a project, deployment project or repository entity, Bamboo checks entity-level restrictions:

  • If no restrictions are configured, access is granted.

  • If restrictions exist, access is granted only when the entity matches the allowed list.

Configuring Bamboo Connector

Add or update the following parameters in the <Connector> section in your server.xml file. Replace the proxy name as needed.

<Connector
    ...
    secure="true"
    scheme="https"
    proxyName="your-proxy.example.com"
    proxyPort="443"
    ...
/>

How service accounts work in Bitbucket Data Center

Supported scopes

Bitbucket currently supports the following scopes for service accounts:

Endpoints requiring ADMIN, SYSTEM_ADMIN, REPO_ADMIN, or PROJECT_ADMIN privileges are not available through OAuth 2.0 calls.

The first layer of security is scope verification at the endpoint level. This mechanism is consistent across all Atlassian products.

For more information, see Link to other applications.

Endpoints accessible with service accounts

Service accounts can be used to access all Bitbucket REST API endpoints listed on Bitbucket Data Center REST API .

Permission system for service accounts

The second layer of security is Bitbucket’s permission system, which defines how access is granted to projects and their repositories.

Normally, permissions in Bitbucket are assigned to groups, roles, or specific users. Service accounts differ because they aren't standard principals – they can’t be added to groups or configured in permission schemes.

As a result, permission checks for OAuth 2.0 calls behave differently:

• Admin permissions
  If the required permission is ADMIN or SYSTEM_ADMIN, the request is automatically rejected.
• Non-admin actions
  If the action involves an entity (like project, repository, etc), Bitbucket checks entity-level restrictions:
  • If no restrictions are configured for the service account, access is granted.
  • Access is granted to the entity only when the restrictions (projects or repositories) match for that service account.