After working with Atlassian’s 3LO OAuth 2.0 flow for the last few weeks, I have to say: it’s shockingly underbaked. I’m honestly surprised this is the state of things in 2025, given how critical OAuth is for any serious integration.
Let me walk through just how bad it is.
Only One Redirect URI — Seriously?
Atlassian only allows a single callback URL per OAuth app. That means:
- No clean way to support multiple environments (dev, staging, prod)
- No regionalization (
us-east.mydomain.com,eu-west.mydomain.com, etc.) - No multi-tenant handling with per-tenant redirects
This is OAuth 101 — most platforms (GitHub, Google, Microsoft, etc.) allow multiple redirect URIs or even wildcards with validation. But not Atlassian. Their workaround? Create X separate apps. Seriously?
accessible-resources Returns Everything
Once a user consents to a single Jira site, the /oauth/token/accessible-resources endpoint returns every Jira instance they have access to. There’s no way to know which one the user actually authorized.
This violates OAuth 2.0 standards (RFC 6749 §5.1), which clearly state the token response should reflect the scope actually granted.
Atlassian’s design completely breaks the idea of resource-specific consent. You have to guess which site to use.
Real Security Risks
Worse, until recently, Atlassian would silently union scopes across sites. So if a user granted additional permissions on Site B, those scopes might show up for Site A — even if they weren’t granted there. This was confirmed by Atlassian and only fixed in late 2024.
Think about that for a second. Your app might think it has permission on Site A, when it doesn’t. Or worse, might try to access Site B assuming the same scopes apply. It’s a security and UX nightmare.
What Atlassian Should Do (but hasn’t)
At this point, here’s the bare minimum that should happen:
Allow multiple or wildcard redirect URIs
Include the authorized Cloud ID in the /oauth/token response
Bind the token to a specific resource
Provide clear error messages (e.g., “App not installed on this site”) instead of generic 403s
Actually follow the OAuth 2.0 spec
And No, These Aren’t “Edge Cases”
These aren’t corner cases. These are real-world, daily developer needs. Every serious SaaS integration supports multiple environments. Every region-aware app needs tenant-specific redirects. Every secure system needs per-resource consent.
And Atlassian, one of the biggest B2B platforms in the world, just… doesn’t?
Final Thoughts
OAuth is supposed to be the secure foundation for third-party integrations. Atlassian’s version feels like a beta from 2012. No one wants to juggle 10 apps just to support a dev/test/prod pipeline. No one wants to guess which Jira instance a token is for. And no one wants to explain to a customer why they suddenly can’t create tickets.
If you’re building anything serious on top of Atlassian, be warned: their OAuth flow is not production-grade.
And that’s a shame — because the rest of their platform is actually pretty solid.
