OAuth Support for Service Accounts

[#1]

Hi Atlassian community,

My name is Kunwar, and I am a product manager responsible for cloud security here at Atlassian.

We’re excited to introduce the next leap for service accounts: OAuth 2.0 support with the client credentials flow. Building on your momentum with API token-based service accounts, this release brings a new level of security and flexibility toyour automated integrations.

You can connect your systems with OAuth 2.0, a standards-based authorization method. This method improves security. You do not need to use hard-coded tokens or share credentials. A hard-coded token is a credential that you manually place in your code or configuration files. If someone gains access to your code, they can see and use the token to access your systems. OAuth 2.0 removes this risk by providing a secure, standards-based way to authorize integrations.

Why OAuth 2.0 for service accounts?
Service accounts empower organizations to automate securely and at scale. With this release, we set a new standard for control and flexibility. OAuth 2.0 (client credentials flow) gives admins and technical teams more options to manage integrations with precision. With OAuth 2.0 client credentials:

• apps not individuals authenticate seamlessly

• API security improves with audit log activity and granular permissions

• machine to machine access without long-lived tokens or shared credentials

Who is this for?

If you’re an admin securing third-party or internal integrations, or if you’re implementing backend services and bots that manage integrations, you can use OAuth 2.0 for service accounts.

How to use API scopes?

• Jira REST API scopes
• Confluence REST API scopes

How to get started

1. Create a service account in Atlassian administration.

2. Choose your authentication method:

1. OAuth 2.0

2. API token

3. Give a name to your credentials.

4. Select API scopes based on your needs.

5. After reviewing your information, create the credentials and save them somewhere safe.

 

What subscription plan do you need for service accounts?

You'll get 5 free service accounts to start. Need more? Upgrade to:

• Atlassian Guard Standard: Up to 250 service accounts
• Cloud enterprise: Up to 1,000 service accounts, plus priority support, custom integrations, and SLAs

Best Practices

• Use a separate account for each integration to improve security.
• Check permissions often to maintain control.
• Change secrets regularly to ensure safety.
• Review logs to spot problems.

Service accounts for Data Center apps

Service accounts for Data Center apps will launch in Q4 of 2025 and are now available for testing in EAP program. The feature also supports OAuth2.0 as the primary authorization method. For Data Center customers planning their migration to Atlassian Cloud, service accounts will simplify external integrations and provide a more secure foundation for the transition. If service accounts could benefit your Data Center use case, we invite you to join our EAP program.

Share your experience

The service account journey has been shaped by your feedback, and that partnership continues. Please:

• Share your experience - how is OAuth 2.0 working for your team?

• Ask questions or surface any bumps you encounter.

• Suggest features that would help you scale or secure your integrations further.

Drop your thoughts in the comments or reach out directly to our product and support teams. We’re committed to making integrations as safe, powerful, and easy as possible.

Thank you for helping move our platform—and its integrations—forward!

Cheers, 

Kunwar

[Shawn Stevens]

@Kunwardeep Singh Awesome. I would be curious if Atlassian or others have a preferred naming convention or suggestion on a good way to name these services accounts and then if you have API Tokens tied to a service account. 

Would be curious to see what Atlassian or others think. 

[Yatish Madhav]

Thanks @Kunwardeep Singh  - i have not started using our service accounts yet but looking forward to switching to them and using them

Question (since we have been having performance issues on Jira) - i created a support ticket some time ago and the engineer told me that it may be due to some third-party apps, our own custom app or the various API calls that we do via our app or user API tokens. Eg we call the issue search a lot if there are many issues to process, etc - performance issues is even if we handle rate limiting with retries, exponential backoff, etc- So, would the oAuth tokens/secrets and API calls done this way affect our front end Jira performance taking the above into consideration or is it independant of any/all other API call/methods and front end actions done?

@Shawn Stevens that is very valid and great to know too! They way we handle naming conventions is be trying to cover 2 things - short/to the point names and detailed enough to give an idea of what the purpose of it is ... that is easier said than done sometimes. One example of naming we have is eg. Jira - <ThirdPartyToolName> or snake/kebab/pascal/camel case if spaces are not allowed

Thanks

[Mathieu Truchot]

Hello!

Is there a way to use this authentification method in Automation outgoing webhooks ?

[Shawn Stevens]

Something else that I noticed is that Service Accounts use the internal default groups. My company moved to most access is controlled by the IDP and AD groups and at some point someone removed the JIRA default internal admin group. For example I was setting up a Service account and I wanted to select Jira App Admin, but because the default group no longer exists it won't keep the APP admin settings and reverts back to user.  

I'm pretty sure i can re-create the internal Jira Admin group, but it was something I noticed.