Does Storing OAuth Tokens in Forge Remote DB Count as Storing Personal Data?

Forge
1

Hi guys,
We have a question regarding our app’s privacy and security compliance.

We are developing a Confluence Forge app that uses OAuth 2.0 to access data from a Jira site. Currently, we store the OAuth refresh token, access token, and token expiration time (or potentially only the refresh token) in Forge Remote database(Heroku postgre).
Would storing only these authentication tokens be considered “storing personal data” under Atlassian’s policies?

We found an older community discussion stating that OAuth tokens themselves are not considered personal data and therefore do not require personal data reporting: Do I have to implement Personal Data Reporting in my OAuth2 app? . However, as the discussion is several years old, we would like to confirm whether this guidance is still valid.

Additionally, are there any specific requirements, restrictions, or best practices that Atlassian recommends for storing and managing these tokens to ensure compliance with Atlassian’s privacy and security requirements?

Thank you for your clarification.

2

That specific thread does not say anything about OAuth tokens. It only asserts that the account ID is not considered PII.

What does Atlassian say about OAuth tokens

tl;dr: you are required to store OAuth tokens on the Forge platform, either by using Forge OAuth providers or by using Forge encrypted storage

With regard to storing OAuth credentials, please be advised that Atlassian has published a security requirements policy document for Cloud apps: https://developer.atlassian.com/platform/marketplace/security-requirements/

With regard to storing OAuth tokens, it says:

An application must securely store and manage secrets, which include OAuth tokens, Trello tokens, sharedSecret, API keys, and encryption keys. They cannot be stored in places that are easily accessible

It recommends to use the Forge OAuth provider implementation. If this is not suitable for your use case, the implementation details of the requirement instructs us to use either environment variables or use Forge KVS encrypted storage.

Please note that following these security requirements are not optional

Article 8.4, section f) of the Atlassian Marketplace Partner agreement explicitly states that you have an obligation to adhere to this policy:

You will also comply with any security, coding practices, authentication, encryption, or other requirements for Marketplace Apps in the Security Requirements. You agree to remediate all security vulnerabilities identified to you by Atlassian within the timeframes described in the Security Requirements.

Given that this is not optional, Forge apps should either use Forge OAuth providers or use Forge encrypted storage for OAuth keys. As such, data reporting is not required as the OAuth tokens will never leave the Forge platform.

3

@LiaTran I’m not a lawyer, but from a practical compliance view, OAuth tokens are credentials linked to a specific user identity. Most privacy frameworks, like GDPR and CCPA, consider them as personal data or at least as data that can access personal data.

Here’s what I’d check:

  • Atlassian’s privacy policy for Marketplace vendors. They require you to report what data you store. Tokens usually fall under “user data” or “authentication data.”
  • Forge Remote encryption. Forge Remote storage is encrypted at rest, but this does not change how you classify what you store. It only affects your security controls.
  • Your own privacy policy. If you mention storing “authentication tokens” or “user credentials,” you’re covered. If you only say, “we don’t store personal data,” you have a gap.

One thing that might make this simpler: if you can avoid storing the token entirely and instead use @forge/api with asUser() for every request, you won’t hold the credential—Atlassian’s authentication layer will. This could be worth looking into if it fits your use case.

Has anyone from Atlassian confirmed the classification officially?