I’m not familiar with Azure KeyVault. I’m not sure what a higher tier admin system is in this case, but it sounds like one solution would be to have the admin system perform the refresh token exchange so that it can store the new refresh token. The rationale we have for rotating refresh tokens is to detect breaches and invalidate compromised tokens as described in the refresh token rotation section in RFC 9700.
Ideally we will have solutions that don’t require 90 day manual intervention. Are the application use cases you’re describing consent based OAuth 2.0 3LO cases?
@IainDooley , I understand that if and when we deprecate the existing tokens it will impact a number of our partners like yourself. Unfortunately I can’t commit to keeping the existing system indefinitely. There unfortunately is cost and risk associated with maintaining legacy systems. That said, Trello has not yet released OAuth 2.0 3LO and is still investigating Atlassian API tokens and other solutions, deprecation is still a ways out. I want to be clear that eventual deprecation is likely, but we intend to provide the best solutions possible for migration for our current partners and the future of the Trello ecosystem.
Hey Steve,
Yep so the expectation I have set for my customers still using these systems is that they will stop using them within 12-18 months and that probably means they will look for another platform that has the features our automations are providing.
Thanks
Iain
1 Like
@SteveRonderos - I appreciate the updates, but I need to address some critical concerns that go beyond the immediate technical scope of this RFC. As both myself and someone supporting @IainDooley’s position, I’ve researched this extensively and the evidence strongly suggests that maintaining the current API token system alongside OAuth2 is not just feasible—it’s strategically essential.
Industry Precedents Prove Dual Systems Work
GitHub has successfully operated Personal Access Tokens, OAuth Apps, GitHub Apps, and workflow tokens simultaneously for years. They didn’t force migration—they enhanced their token system with fine-grained permissions while maintaining backward compatibility. Result? 99.9% successful adoption without ecosystem disruption.
Google Cloud Platform runs service accounts, OAuth2, and Application Default Credentials concurrently across their entire infrastructure. If Google can maintain multiple auth systems at planetary scale, Atlassian certainly can.
Microsoft recently migrated their Authentication Methods Policy with a reversible three-phase approach and 18-month timeline—and they maintained feature parity throughout. They understand that forced migrations destroy trust and business value.
AWS has maintained both temporary credentials and long-term access keys for over a decade. Rather than deprecating either, they provide guidance on when to use each method.
The Technical Reality: API Tokens Are Superior for Key Use Cases
Server-to-Server Communication
- OAuth2: 200-500ms token refresh latency, concurrency limits, complex error handling
- API Tokens: Direct authentication, zero refresh interruptions, minimal dependencies
CI/CD and Automation
- OAuth2: Requires browser flows, callback URLs, external service dependencies
- API Tokens: Header-based auth, deterministic behavior, works with standard HTTP tools
Implementation Complexity
- OAuth2: Days of integration time, specialized libraries, JWT handling, PKCE implementation
- API Tokens: Hours of integration time, standard HTTP clients, straightforward debugging
The Business Case Is Overwhelming
Real-World Destruction Examples
Twitter/X’s forced API changes killed Apollo, eliminated 99% of their developer ecosystem, and triggered mass platform abandonment. Christian Selig, Apollo’s developer, documented the exact process of how forced API changes destroy businesses built on platforms.
Reddit’s API pricing forced shutdown of major apps overnight, triggered protests from 8,000+ subreddits, and permanently damaged the platform’s relationship with its developer community.
Economic Impact Data
- Migration costs: Average 16 months per application
- Hidden costs: 60% productivity reduction during migration, 40% increase in bugs
- Trust erosion: Requires 2x positive experiences to offset each negative incident
Security Analysis: The Myth of OAuth2 Superiority
Properly implemented API tokens can include:
- Automatic expiration (15-60 minutes with refresh)
- Scoped permissions matching OAuth2 granularity
- Regular rotation and comprehensive auditing
- Multi-factor authentication integration
OAuth2’s complexity creates security risks: Implementation errors, misconfigured redirect URIs, and token management complexity often introduce vulnerabilities that simple API tokens avoid.
Real-world data: Both authentication methods show similar vulnerability patterns. Implementation quality matters more than the fundamental method choice.
Platform Stewardship: The Moral Imperative
Steve, you’ve mentioned “cost and risk” of maintaining legacy systems, but let’s examine the full cost equation:
Cost of Maintaining Both Systems
- Engineering resources for dual authentication support
- Documentation and developer support overhead
- System complexity management
Cost of Forced Migration
- Complete ecosystem disruption affecting thousands of developers
- Legal risk exposure from breaking implied contracts
- Competitive disadvantage as developers flee to more stable platforms
- Trust destruction requiring 18-24 months to rebuild
- Loss of network effects that drive platform value
The economics strongly favor maintaining both systems.
Concrete Solutions
Technical Implementation
- Authentication Gateway Pattern: Route requests through a unified system supporting multiple token types
- Enhanced API Token Scoping: Add repository-specific permissions and time-limited access
- Automatic Token Rotation: Implement secure refresh mechanisms for API tokens
- Unified Authorization: Consistent permission checking regardless of authentication method
Migration Strategy (for those who choose to migrate)
- 18-month minimum timeline with extensive developer support
- Comprehensive migration tools and documentation
- Side-by-side operation during transition period
- Feature parity guarantee between old and new systems
The Competitive Advantage
While other platforms (Twitter, Reddit) have damaged their developer ecosystems through forced migrations, Trello can differentiate itself by being the platform that:
- Respects developer investments and existing integrations
- Provides choice rather than forcing unnecessary complexity
- Maintains backward compatibility as a core value proposition
- Prioritizes ecosystem health over short-term cost optimization
The Bottom Line
Steve, the overwhelming evidence from industry precedents, technical analysis, business impact studies, legal considerations, and ethical obligations all point to the same conclusion: maintaining both authentication systems is not just possible—it’s the right business decision.
GitHub, Google, Microsoft, and AWS all successfully operate multiple authentication methods because they understand that different use cases require different solutions. API tokens aren’t “legacy”—they’re the optimal solution for many scenarios.
The developer community isn’t asking for the impossible. We’re asking for what every other major platform provides: choice, stability, and respect for existing investments.
I urge Atlassian to:
- Publicly commit to maintaining API tokens alongside OAuth2
- Enhance rather than deprecate the existing system
- Lead the industry in responsible platform stewardship
- Preserve the trust that makes Trello valuable to its developer ecosystem
The research is clear, the precedents exist, and the business case is compelling. Maintaining both systems is not just technically feasible—it’s strategically essential for Trello’s long-term success.
Thank you @IainDooley and others for clearly articulating these concerns. The developer community stands together on this issue because our businesses and our customers depend on platform stability.
4 Likes
Thank you for your thoughtful feedback and highlighting the importance of supporting both the existing API token system and OAuth2 during this transition.
We absolutely recognize the value in minimizing disruption for developers and users who rely on the current API token system, especially for automations. As outlined in the RFC and our internal planning, our approach is to introduce OAuth2 as a modern, secure, and interoperable standard, while also being mindful of the roll out challenges and business risks. We want to acknowledge that OAuth 2.0 will not completely replace Trello Auth - there are important use cases that are not well-suited to OAuth 2.0 today. We are actively exploring how to support these scenarios with modern authentication solutions, so that all developers and customers have a secure and supported path forward. Our goal is to address longstanding customer concerns and improve Trello’s overall security posture as we evolve our authentication systems.
Key points on our roll out strategy:
- No immediate deprecation: We are not announcing a deprecation date for legacy tokens or OAuth 1.0 at this time. The RFC is intended to gather feedback and build consensus before any enforcement policy or timeline is set.
- Dual support during transition: Both Trello tokens (OAuth 1.0) and Atlassian tokens (OAuth 2.0) will be valid in Trello’s REST APIs for a period after OAuth 2.0 launches. This dual support is designed to ensure a smooth roll out and to reduce risk for existing integrations.
- Phased roll out: We will require all new OAuth clients (at a later date) to use modern auth methods only after all necessary mechanisms are generally available and with ample notice. This will not be enforced until every critical use case - including those not yet covered by OAuth2 - has a secure, supported solution. To ease the transition, we plan to offer guides, documentation, code samples, support channels, automation tools, and early access programs to help developers adopt new auth mechanisms smoothly and confidently.
- Community feedback is critical: We are actively seeking input on challenges, especially around authorization, scopes, and resource restrictions, and token expiry. Your feedback will and has directly influenced our roll out plan and timelines.
Industry precedent is important, and we are closely studying models like GitHub’s dual token support. Our goal is to balance security, interoperability, and developer experience. We are committed to providing clear adoption paths, updated documentation, and example applications to support you through this change.
If you have specific use cases or concerns - especially around personal API tokens, non-3LO API automation workflows, or Power-Ups - please continue to share them. We want to ensure that our approach addresses real-world needs and avoids unnecessary disruption. The developer community is extremely important to us and we appreciate the patience as we carefully consider your thoughts and pave the best path forward.
Thanks for engaging with us on this important transition!
A lot of people don’t bother to even check for changes until something breaks so probably haven’t seen this post.
I agree with others that multiple auth methods need to be maintained. Changes like this is a major breaking change and/or the money and time may not be available to developers and companies to even make these changes.
Customers have come to rely on Trello and have built automations for their workflow from the pitch that Trello has a robust API.
@FredGaloso When do you expect to launch OAuth2 for Trello?
Our team building OAuth 2.0 capabilities for the Trello API is projecting a release in early 2026, if not sooner.
The new OAuth 2.0 system will launch as an opt-in option when creating new PowerUps. The launch will be accompanied by tutorials and support documentation. Once available, we will work closely with the community to address feedback.
As Fred mentioned, we aim to minimize disruption for developers and users relying on the current API token system. The existing token system will continue to function as it does today when we launch OAuth 2.0
OAuth 2.0 3LO is the first step in modernizing Trello’s API authentication system. We on the Trello team appreciate your feedback.
1 Like
If we are targetting it for early 2026 how can following be honoured as there is no 3LO yet for trello ?
@priytams Thank you for your question and for referencing the Atlassian blog article on building secure and scalable integrations.
To clarify, Trello is currently in the process of building OAuth 2.0 support and does not yet support Forge. As a result, the specific instructions outlined in the Work Life article—particularly those related to OAuth 2.0 and Forge under “Our “security-led approach”” — do not currently apply to the Trello ecosystem.
Additionally, our RFC-89: Introducing OAuth2 to Trello is focused on Trello tokens, not personal API tokens, so the guidance around personal API token migration and timelines mentioned in the Work Life article are also not relevant for Trello at this time.
That said, there are established security requirements for apps (including Power-Ups and integrations) within the Trello ecosystem. You can find these on our Security requirements for cloud apps page. We recommend reviewing these requirements to ensure your app remains compliant.
If you have any further questions or need clarification on Trello’s security requirements, please don’t hesitate to reach out to our developer support team—we’re here to help!