Reminder: Migrate from using API tokens to officially supported authentication for Atlassian apps & integrations

Announcements
, , , ,
1

Hi Marketplace partners, following our earlier guidance on building secure, scalable integrations https://www.atlassian.com/blog/developer/building-secure-and-scalable-integrations-our-guidance-for-third-party-apps , this is a reminder to complete your migration away from collecting or storing Atlassian API tokens (Cloud) and to use officially supported authentication (Forge or 3LO/OAuth 2.0).

Additionally, Atlassian is introducing new controls that will impact API tokens usage:

Whats Changing

  • Apps and integrations should not instruct customers to generate/share any API tokens belonging to Atlassian accounts (including user and admin), and apps must not store Atlassian user credentials.

  • Migration deadline: Complete the authentication migration by December 31st, 2025.

  • Enforcement timeline: starting January 1st, 2026, apps that continue to collect or store personal API tokens will be subject to enforcement and may no longer be supported.

Support:

  • If you received an ADDON ticket from Atlassian regarding API token collection, please continue to collaborate with us. Atlassian is committed to supporting your app and assisting you as we explore migration steps.

  • If you did not receive an ADDON ticket but believe your app is impacted, contact our developer support portal https://ecosystem.atlassian.net/servicedesk/customer/portal/34/group/109/create/579 before December 31st, 2025, so we can review your case.

Take Action Now:

  • Review and update your app or integration to use officially supported Forge or 3LO/OAuth 2.0 authentication and remove any collection or storage of personal API tokens.

  • If you haven’t already done so, reply in your ADDON ticket with all endpoints your app uses to authenticate with API tokens, and share your migration plan.

  • Your app uses API tokens and you did not receive an ADDON ticket, contact support before December 31st, 2025 to initiate a review.

For best practices, please see Atlassian’s guidance:

1 Like
2

Can you elaborate if and how this affects service accounts? Understand service accounts | Atlassian Support

4 Likes
3

Hello @SrivathsavGandrathi

This is a tiny gripe, but Personal Access Tokens (PATs) are for the Data Center products, not the Cloud products. Avoid using the acronym ‘PAT’ when referring to Cloud API Tokens.

4

Thank you for the feedback, i corrected the post.

5

@andreas.schmidt Let me get back to you on this.

1 Like
6

To clarify, the guidance to migrate away from API tokens to officially supported authentication methods applies equally to both user accounts and service accounts. From a security perspective, API tokens—whether generated for a user or a service account—present the same risks when shared or stored by third-party apps and integrations.

7

Hi @SrivathsavGandrathi,

how about general purpose apps/integrations where the user can define arbitrary web requests to any user defined URL? Can these still use API tokens?

Atlassian’s own Jira Automation has a Send web request action. We e.g. use one rule to update an existing version and since there is no specific action for this, we use the Send web request action with an API token for authentication.

2 Likes
8

@t-bundt The security risk still applies if an app specifically prompts users for an Atlassian API token. However, if the ‘web request’ feature is truly generic allowing users to call any API with any token, i dont see how we can enforce that usecase.

9

Following on from this, what about the scenario where an Atlassian API token is used to validate personal requests to a specific Jira/Confluence endpoint?

(Whilst Tenant A would perform asApp/asUser requests for Site A, and Tenant B for Site B, all tenants would point to Site X and authenticate via a pre-determined API token) - It sounds like this behaviour is also no longer accepted due to authorization via an Atlassian API token?

Requesting as app in this scenario would require new Forge scopes for the endpoints that would be called in replacement of an API token (even if unused for the tenants own site).

Am I right in stating that using external egress to the Site X and removing API token auth is the approach here? (The app cannot authenticate and scopes cannot be considered for a chosen site, user consent would list these scopes for their site, even if when granted it is only used for a single site URL across all tenants).

2 Likes
10

We have the same issue as mentioned by @DennyMiller . Atlassian has granted us an exemption until a replacement API is ready.

However as far as I know, no replacement API has been published by Atlassian.

2 Likes
11

I am developing a private app for one customer, to be owned and controlled by that customer and installed privately on their site. Does this restriction apply to this kind of private app?

12

@DennyMiller If you are talking about cross-site requests from Site A to Site X, you are correct that Forge asApp and asUser scopes are strictly bound to the installation context (e.g., Tenant Site A). They cannot be used to authorize requests to a different Atlassian site (Site X).

Yes, your stated approach is correct, authentication must not be done via API tokens. Can you try Forge External Auth that allows you to connect to third-party services via OAuth 2.0 flow, using it to connect back to another Atlassian instance (Site X)?

13

@marc We have especially moved away from exemptions as stated here: https://developer.atlassian.com/changelog/#CHANGE-2449. We are trying to approach current use cases by addressing them case-by-case (that are only blocked on API support), and after January 1st, 2026, use cases or apps that are not known to us will be enforced by default.

14

@ChrisHardin as stated, security risk applies if an app prompts users for an Atlassian API token. Current enforcement initiative targets Marketplace listed apps but the overall guidance is, apps must not prompt, collect or store API tokens belonging to Atlassian accounts. So yes, this restriction still applies for your app.

15

@SrivathsavGandrathi Forge External Auth doesn’t work with Confluence. Once I added a Confluence client id to the manifest, the manifest failed the validation with the following error

Error: Manifest validation failed: Invalid client id fw5YaSCLFtGX5cYk7A9wE3AqtQTWMpE6: Atlassian credentials are not supported in auth providers. (requestId: c1f5c3b9-8e42-407d-ba4e-50b13f21b7b2)

How can we access other Confluence sites from Forge?

Thanks

2 Likes
16

@SrivathsavGandrathi More specifically, we are having users pass API Token Auth headers to our Forge web triggers. Our web trigger code then uses the API tokens to make requests to Atlassian APIs on behalf of the remote user. Technically, our app doesn’t actually collect or store the API Token, just passes it along to an Atlassian API. Is there a recommended alternative to support authentication into Web triggers from remote integrations?

4 Likes
17

Hi @SrivathsavGandrathi ,

We created a ticket on November 24th. Today, 12 days later, it is still in status new.

18

@ashraf.teleb85 Seems like this External Auth setup is not yet supported. Currently cross-site access may not be supported by Forge natively, have you raised any Forge feature request ticket?

19

@ChrisHardin Native authentication isn’t yet available for Forge web triggers. For now, apps are expected to implement their own authentication for incoming web trigger requests.

20

@marc Are you referring to the ADDON ticket? If so, please note that use cases already known to Atlassian through an ADDON ticket will not be subject to the default enforcement stated in this announcement.

1 Like