Atlassian OAuth 2.0 is an OAuth 2.0 authorisation flow used by Atlassian products and apps to let users grant scoped access without sharing their password. It typically issues access tokens tied to specific permissions, so integrations can call APIs on a user’s behalf while limiting exposure of credentials and reducing direct password handling.
How Atlassian OAuth 2.0 Works
Atlassian OAuth 2.0 is an authorisation layer, not a password-sharing shortcut. It lets an Atlassian user approve a third-party app or integration to access specific data and actions, with scopes defining what the app can and cannot do.
The practical value is separation of trust. The app receives a token representing consented access, while the user keeps their primary password private. That reduces credential exposure and allows organisations to limit integrations to the minimum permissions needed for the task.
Tokens, Scopes, and Consent Boundaries
OAuth 2.0 only works safely when the scope model is understood clearly. A token is not a universal key, it is a bounded credential that should map to a defined resource, permission set, and lifetime. If the integration requests more scope than the use case requires, the consent boundary becomes unnecessarily broad.
That is why OAuth design choices matter for Atlassian apps and APIs. The flow should distinguish who is authorising, what the app is allowed to access, and whether the token is meant for a human delegated session or a more automated service-to-service pattern. The OAuth 2.0 Authorization Framework defines the core model, while OpenID Connect Core 1.0 is the relevant companion when an integration also needs authenticated identity, not just API access.
Why Atlassian OAuth 2.0 Is Used in Integrations
For organisations, the main advantage is reduced direct credential handling. Integrations can call Atlassian APIs without storing a user’s password, which lowers the blast radius of compromise and supports better app segmentation. It also helps separate application access from interactive logins, which matters when multiple vendors or internal tools need constrained access to Jira, Confluence, or related services.
OAuth also gives teams a cleaner governance model for app access reviews. Instead of treating every integration as a shared-account exception, they can evaluate the scopes granted, the user or service context behind the grant, and whether the integration still has a legitimate business need.
Operational and Security Implications
Atlassian OAuth 2.0 should be treated as a controlled delegation mechanism. The security outcome depends on token handling, consent discipline, app trust, and revocation behaviour. Poorly governed OAuth usage can still create excessive access, persistence after user departure, or token abuse if an attacker obtains the token or tricks a user into authorising a malicious app.
Good practice is to prefer the smallest effective scope set, review third-party app trust carefully, and treat oauth token as sensitive authentication material. If you need the underlying protocol detail, the OAuth 2.0 Security Best Current Practice is the clearest reference for modern protections such as sender-constrained tokens and better resistance to token theft. For Atlassian-specific implementation context, the OAuth 2.0 and OpenID Connect Guide for Identity Teams is a useful deeper explanation of grants, scopes, and common mistakes to avoid.
For Atlassian environments specifically, the Atlassian Cloud Security Guide is the best starting point when OAuth is part of a broader admin, app, and permission review.
When to Use It, and When to Be Careful
Use Atlassian OAuth 2.0 when an app needs delegated access to user-approved Atlassian data or actions and you want to avoid password collection entirely. It is usually the right pattern for modern integrations, marketplace apps, and workflows that need scoped API access rather than full account control.
Be careful when the integration really needs non-interactive automation, broad administrative reach, or long-lived access. In those cases, the question is not simply whether OAuth works, but whether the app design, scope choice, secret handling, and revocation model are appropriate for the operational risk. The Atlassian API Tokens Security Guide is a useful adjacent reference when comparing oauth delegation with token-based automation patterns.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | OAuth 2.0 governs how Atlassian apps authenticate API access tokens. |
| Recommendation — Verify Atlassian integrations use strong OAuth client authentication and reject unsafe token handling. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | OAuth tokens enable application and service access to Atlassian APIs. |
| Recommendation — Apply IA-9 to authenticate integrations that call Atlassian APIs on behalf of users. | ||
| OWASP ASVS | V10 — OAuth and OIDC | OAuth 2.0 and consented delegated access are the core mechanism described here. |
| Recommendation — Use V10 to validate OAuth flows, redirect handling, consent, and token security in integrations. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Scoped delegation and app access review are central to safe Atlassian OAuth use. |
| Recommendation — Manage and revoke Atlassian app access through least-privilege access control processes. | ||