Application links and OAuth grants are how Jira and Confluence trust other systems, and most organisations have never reviewed the ones they created years ago. An application link holds a client ID and secret that let another product act against Jira or Confluence, and an OAuth 2.0 grant lets an external app read or change data with a user's rights until it is revoked. Both survive staff changes, product migrations and decommissioned servers. This runbook covers how to inventory and audit application links and OAuth 2.0 integrations in Jira and Confluence Data Center, and connected OAuth 2.0 (3LO) and Forge apps in Atlassian Cloud, then remove what is not needed with a rollback. It is for Atlassian administrators and identity or SaaS security engineers. Personal access tokens and API tokens are covered separately in How to find long-lived personal access tokens across Atlassian.
This is an independent guide from NHI Mgmt Group, based on Atlassian's public documentation as of November 2026. It is not sponsored or reviewed by Atlassian. Menu names and features differ between product versions and between Data Center and Cloud, so confirm against the documentation for your version.
Key takeaways
- Two estates, two inventories. Data Center keeps application links in each product's Administration > Applications > Application links page; Cloud keeps third-party OAuth and Forge apps under Connected apps in Atlassian Administration.
- Incoming links are the risk you own. An incoming link makes your Jira or Confluence the OAuth provider; whoever holds its client ID and secret can request access to your data.
- Scope is capped by the user, not by the app. In Jira Data Center an OAuth 2.0 grant carries READ, WRITE, ADMIN or SYSTEM_ADMIN scope, but never more than the authorising user can already do, so grants made by administrators matter most.
- Logging is not on by default for what you need. Jira Data Center records OAuth 2.0 integration success and failure only at the Advanced coverage level of the Security area.
- Test before you delete. Use Test connection and an observation window; a deleted link has to be recreated on both sides with new credentials.
When you need this
- After a related breach: in the Cloudflare Thanksgiving breach, credentials left unrotated after an earlier identity provider breach gave the attacker access to Atlassian systems. Integration credentials need the same review as user credentials after any upstream compromise.
- After a SaaS integration supply chain incident: the Salesloft Drift breach showed how OAuth tokens held by one integration vendor opened many customer tenants. When a vendor you have connected is breached, you need to know within hours which grants and links it holds.
- Before decommissioning or migrating: links to retired servers or old test instances keep valid credentials on both sides.
- Periodic review: NIST SP 800-53 AC-2 Account Management and CIS Controls v8.1 Safeguard 5.3 expect machine access to be inventoried and dormant access disabled.
Before you start
Work out which kinds of trust you have. The table lists the main integration types this runbook covers.
| Integration type | Where it lives | Who it acts as | Main risk |
|---|---|---|---|
| Application link, OAuth 1.0 | Data Center: Administration > Applications > Application links | The linked product, on behalf of users | Legacy links to retired or test servers that still trust each other |
| Application link, OAuth 2.0 incoming | Data Center: same page, direction Incoming or two-way | Users who authorise the remote app | A client ID and secret that any holder can use to request user grants |
| Application link, OAuth 2.0 outgoing | Data Center: same page, direction Outgoing or two-way | Your users, against the remote product | Your product stores the remote app's client secret |
| External OAuth 2.0 client (generic application) | Data Center: incoming link with application type "Generic application" | The authorising user, within the granted scope | Third-party tools holding long-lived refresh tokens |
| OAuth 2.0 (3LO) app | Cloud: Atlassian Administration > Apps > site > Connected apps | Each user who authorised it | User-installed apps nobody approved |
| Forge or Marketplace app | Cloud: Connected apps | Users and the app's system user | Broad scopes and vendor access to data |
Access: Data Center needs a Jira System Administrator or Confluence administrator; Cloud needs an Organization admin or Site admin. Agree up front who approves deletions, because the owner of an integration is often a team outside IT.
Evidence: keep a copy of every link's configuration (application name, URL, direction, status, scopes) and of the connected apps list before changing anything. These records are your rollback.
Step-by-step
Steps 1 to 5 are read-only. Step 6 is reversible. Step 7 is destructive.
Data Center: Jira and Confluence
- Turn on the right audit coverage first. In Jira go to Administration > System > Audit log, open Settings and set the coverage level for the Security area to at least Advanced. Atlassian's audit event list places "OAuth 2.0 integration succeeded" and "OAuth 2.0 integration failed" in the Security area at Advanced level, so a Base setting will not record them. Check that retention covers your review window: Jira writes audit files to
<Jira local home>/log/auditon each node (up to 100 files of 100 MB each by default), and database retention defaults to three years on new installs. Confluence Data Center has its own audit log; check its event coverage in the Confluence documentation for your version. - Export the application links list from every product. Open Administration > Applications > Application links. For each row record:
- Application: name and version; external apps show as Generic application.
- Direction: Incoming, Outgoing or two-way.
- Status: Connected, network error or non-Atlassian.
- Authentication: OAuth 1.0 or OAuth 2.0, and the scope or permission set on the incoming link.
- Classify each link. Flag links with status network error (the remote end may be gone), links to hostnames that resolve to test, staging or retired servers, OAuth 1.0 links to external (non-Atlassian) applications, which Atlassian recommends moving to OAuth 2.0, and incoming links whose scope is higher than the integration needs.
- Review OAuth 2.0 scopes and who granted them. Jira Data Center as an OAuth 2.0 provider supports the authorization code flow with and without PKCE, and offers four scopes:
Because a grant is capped at the authorising user's own rights, an ADMIN-scoped grant authorised by a system administrator is effectively an administrator credential held by the remote app. Use the audit log's OAuth 2.0 integration events to see which clients are actually used and by whom.
Scope What it allows Audit stance READ View projects and issues Default for reporting and sync tools WRITE Create, update and delete projects and issues; implies READ Justify per integration ADMIN Administer Jira, excluding backups, imports and infrastructure settings; implies READ and WRITE Exception with named owner and review date SYSTEM_ADMIN Full administration including backups and infrastructure; implies all lower scopes Should be rare; challenge every instance - Test each outgoing link. Use Actions > Test connection on outgoing OAuth 2.0 links. A link that fails and that no owner claims is a removal candidate. For incoming links, the audit log success events over your window are the usage evidence.
Cloud: connected apps
- Inventory and restrict connected apps (reversible). In Atlassian Administration select the organisation, then Apps > Atlassian apps, select the site under Sites, then Connected apps. Record each app, its type (OAuth 2.0 (3LO), Forge, Marketplace), and what View app details shows for it, and ask the site's users who installed it. Where only administrators should install apps, select Block user apps in the Connected apps settings. Use More actions > Download logs for apps where you need the vendor log, and consider App logs access > Disable log access where vendor log access is not needed. If you have Atlassian Guard Premium or Cloud Enterprise, the organisation audit log under Insights > Audit log gives the admin activity trail.
Remove what is not needed
- Remove links and apps (destructive). For Data Center, after the owner confirms and an observation window has passed, use Actions > Delete on the application link, then delete the matching link on the remote product. For Cloud, open the site's Connected apps, select Manage authorization for the app and choose Uninstall. Atlassian documents that uninstalling an OAuth 2.0 (3LO) app revokes all users, and uninstalling a Forge app revokes all user and system user grants; connected users are removed automatically and progress is shown on the Connected apps screen. Warn users before you do it. Users can also revoke their own grants at
id.atlassian.com/manage-profile/apps.
Choosing between remove, re-scope and rotate
| Finding | Action | Why |
|---|---|---|
| Link to a retired or unreachable server | Delete on both ends | Credentials with no legitimate holder |
| OAuth 1.0 link to an external app | Rebuild as OAuth 2.0, then delete the old link | Atlassian recommends OAuth 2.0 for external integrations |
| Incoming link with ADMIN or SYSTEM_ADMIN use | Re-scope or move to a dedicated low-privilege integration user | Grants inherit the authorising user's rights |
| Client secret exposed or vendor breached | Recreate the incoming link to issue new credentials, update the vendor, delete the old link | Revokes everything issued against the old client |
| User-installed Cloud app with no owner | Uninstall and turn on Block user apps | Removes the grants and stops recurrence |
| Active, owned, minimal scope | Keep, record owner and review date | Nothing to change |
Verify it worked
- Data Center: the application links page on both products no longer shows the removed links, and no link shows network error without an open ticket.
- Usage: the audit log shows no OAuth 2.0 integration success events for removed clients, and failure events for them stop once the vendor updates.
- Cloud: the Connected apps list matches the approved register, and Block user apps is set where agreed.
- No breakage: owners confirm that remaining integrations (issue sync, dashboards, CI links) work after the window.
Rollback and common errors
| Situation | Fix |
|---|---|
| An integration breaks after a link is deleted | Recreate the incoming link (new client ID and secret), update the remote outgoing link and redirect URI, then use Test connection on both sides |
| Data Center to Data Center link will not complete | Atlassian's method is to create a placeholder incoming link first, exchange credentials, then update the redirect URIs on both sides |
| A Cloud app was uninstalled in error | Reinstall it; every user has to authorise again, so plan communication |
| OAuth 2.0 redirect fails in production | Atlassian requires HTTPS for redirect URIs and base URLs in production |
| No audit events for OAuth 2.0 clients | Security coverage is below Advanced; raise it and restart the observation window |
| Refresh fails after a vendor's retry | In Jira Data Center using a refresh token invalidates the existing access and refresh tokens, so a client that reuses an old refresh token fails by design |
Hardening afterwards
- Use dedicated integration users: authorise OAuth 2.0 grants with a non-administrator account that holds only the projects and spaces the integration needs.
- Keep a register: record each link and app with owner, purpose, scope and review date, and reconcile it with the product lists quarterly. See the SaaS and OAuth App Governance Guide.
- Prepare a vendor breach response: know how to revoke a single integration within an hour. See the OAuth Token Theft Incident Playbook.
- Harden the platform around the links: see the Confluence Data Center Hardening Guide and the Atlassian Cloud Security Guide.
- Watch for consent phishing: user-installed OAuth apps are a target for illicit grants. See the Consent Phishing and Illicit OAuth Grants Guide.
Small instance or large estate
A single Jira and Confluence pair usually has a handful of links that one administrator can review in an hour. An estate with several Data Center products, a Cloud organisation and many sites should export the lists on a schedule, send audit logs to the SIEM, and give each integration a named owner in the register so that review becomes reconciliation rather than investigation.
Metrics
| Metric | Direction |
|---|---|
| Application links with status network error | Zero |
| OAuth 1.0 links to external applications | Falling to zero |
| Integrations with ADMIN or SYSTEM_ADMIN scope | Few, each with an owner and review date |
| Connected Cloud apps without a register entry | Zero |
| Time to revoke one integration after a vendor breach | Under one hour |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 Account Management; AC-6 Least Privilege | Inventory and scope of integration access |
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management | Client secrets and token lifecycle |
| NIST SP 800-53 Rev 5 | AU-2 Event Logging; AU-6 Audit Record Review | Audit coverage for OAuth events |
| NIST CSF 2.0 | PR.AA-05; DE.CM-03 | Access permissions reviewed; technology usage monitored |
| MITRE ATT&CK | T1528 Steal Application Access Token; T1550.001 Application Access Token | Theft and reuse of OAuth tokens held by integrations |
Practitioner checklist
- Set Jira audit Security coverage to Advanced and confirm retention.
- Export application links from every Data Center product, both ends of each link.
- Flag links in network error, links to retired hosts and OAuth 1.0 links to external apps.
- Review OAuth 2.0 scopes and which users authorised ADMIN or SYSTEM_ADMIN grants.
- Inventory Cloud connected apps per site and decide on Block user apps.
- Confirm owners, observe for one cycle, then delete links and uninstall apps.
- Recreate links with new credentials when a secret or vendor is exposed.
- Keep a register with owner, scope and review date for every integration.
Standards and references
- Atlassian: Link to other applications (Confluence Data Center)
- Atlassian: Link to Atlassian products using OAuth 2.0
- Atlassian: Jira OAuth 2.0 provider API
- Atlassian: Auditing in Jira
- Atlassian: Audit log events in Jira
- Atlassian: Manage your organization's Marketplace and third-party apps
- Atlassian: Track organization activities from the audit log
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Confluence Data Center Hardening Guide · Atlassian Cloud Security Guide · How to find long-lived personal access tokens across Atlassian · SaaS and OAuth App Governance Guide