Marketplace security requirements: is a customer-supplied Git provider PAT stored with kvs.setSecret acceptable for a Forge app?

Forge Forge Platform and Tools
1

Hi all,

I’m preparing a Forge app for the Marketplace and would like to check one design decision against the 2026 “Security requirements for cloud apps” before I submit.

The app. A Jira project page (plus a project settings page and an issue panel) showing revert-based Change Failure Rate / MTTR. It reads commit metadata (message, date, SHA — no source code) from the customer’s Git provider (GitHub, GitLab, Bitbucket Cloud, Azure Repos) through permissions.external.fetch.backend, and can optionally export events to the customer’s own BigQuery table or S3 bucket. Scopes: storage:app, read:jira-work. No web triggers, no remotes. Each resolver checks the calling user’s Jira permission via /rest/api/3/mypermissions (called asUser()): Browse for viewing, project-admin for settings and sync.

How authentication works today. A project admin pastes a read-only, fine-grained token of their own Git provider account (for example a GitHub PAT with Contents: read-only). It is stored per project with kvs.setSecret, is never shown in the UI again, is never logged, is never returned to the frontend, and is only sent in the Authorization header to the provider’s API host declared in the manifest.

Why not Forge’s external authentication (asUser().withProvider). Credentials there are per Jira user, and the raw token can’t be reused at project level. The whole point of the dashboard is that PMs and executives who have no repository access can still see it, so a shared project-level credential is required.

My questions

  1. The requirement says external OAuth2 clients “must use Forge’s OAuth2 Providers unless a required capability is not supported”. Is a customer-supplied, read-only, third-party PAT stored via kvs.setSecret in scope of that requirement at all, or does it fall under “must securely store and manage secrets” (which lists setSecret as the Forge approach)? I read the PAT prohibition as covering credentials of Atlassian user accounts only — is that correct?
  2. Would a reviewer accept this design in the security questionnaire, given that the provider-managed flow can’t provide a shared project-level credential? Has anyone gone through review with a comparable pattern?
  3. If not, what is the recommended pattern for a shared, project-level credential to a third-party API (e.g. a webtrigger-based OAuth flow with app-level token storage)?

Docs I’m relying on: Security requirements for cloud apps (last updated Feb 19, 2026), the secret store (kvs.setSecret) reference, and the External authentication reference.

Thanks in advance!

2

We store OAuth tokens in external storage and have not had any question or complaint with regard to security requirements. So I would just go ahead, and if Atlassian gives you flack for it you can just point them to this precedence

3

We as well store OAuth tokens. Similar to you, the OAuth per user tokens are stored in the kvs.setSecret.

Our main reason: Existing well tested code path not worth rewriting + alternative auth options + user defined OAuth options, etc. It just does not fit into the Forge OAuth 2 provider.

So, yes, it is fine to use the Forge secret store.