Migrate from Workfront OAuth2 to Adobe Developer Console
Workfront’s legacy custom OAuth2 application service (the integrations you set up under Setup > System > OAuth2) is being retired. Going forward, all custom integrations that authenticate against Workfront must use the Adobe Developer Console (developer.adobe.com) authentication flow instead.
This change affects any custom-built integration, script, or third-party tool that currently authenticates using a Workfront-issued OAuth2 client ID and secret. It does not affect how you log in to Workfront, and it does not affect standard, Adobe-managed integrations such as the packaged Microsoft Teams or Slack integrations, which Adobe is migrating separately.
Access requirements
| table 0-row-2 1-row-2 layout-auto html-authored no-header | |
|---|---|
| Adobe Workfront access level configurations | System Administrator |
| Adobe Developer Console rights | Full IMS Org admin rights are required to access Adobe Developer Console for Workfront. This is broader than a Workfront product admin role, since it manages the whole Adobe org and all products under it. |
Key dates
Affected organizations
Your organization is affected by this change if it has any integration, script, or tool that connects to Workfront using a custom OAuth2 client ID and secret issued through Workfront’s legacy OAuth2 setup screen. Common examples include:
- Custom-built integrations your engineering team maintains against the Workfront API.
- Third-party or partner-built connectors configured with a Workfront-issued client ID. We recommend checking with your vendor if you’re not sure how their integration authenticates.
- Internal automation, reporting, or data-sync scripts that call the Workfront API directly.
If you don’t know whether your organization has any of these, your Workfront administrator can check the OAuth2 applications list under Setup > System > OAuth2 to see what’s currently registered. For information, see View and Manage Custom OAuth2 Applications.
Understand Adobe Developer Console authentication types
Adobe Developer Console supports more than one way to authenticate. You can select the type that matches how your integration works:
-
Server-to-Server Authentication: For an application running on your backend that calls Adobe APIs on behalf of your organization, with no end user involved. This is the closest match to the legacy Workfront OAuth2 pattern worked with client IDs and secrets, and is the type most custom Workfront integrations, scripts, and automations should use.
-
User Authentication: For cases where an Adobe user needs to sign in and grant consent before your application can view or edit their data. If your integration needs to act on behalf of a specific signed-in Workfront user rather than your organization as a whole, use this type instead.
If you choose User Authentication, there are three further options depending on your application’s architecture:
- OAuth Web App: For applications with a frontend UI and a backend server. The server securely stores the client secret and fetches tokens.
- OAuth Single-Page App: For browser-only web applications with no backend server. The web app itself fetches tokens.
- OAuth Native App: For mobile or desktop applications that run natively on a device and have no backend server. The native app fetches tokens.
Most organizations migrating a backend integration, script, or automation off the legacy OAuth2 service want Server-to-Server Authentication.
Feature comparison: legacy OAuth2 vs. Adobe Developer Console
The legacy Workfront OAuth2 service (fount in Setup > System > OAuth2 Applications) offers three application types, with a limit of 10 OAuth2 applications per Workfront instance. Here’s how these aspects compare to Adobe Developer Console:
Migration procedure
If you are a Workfront System Administrator
-
Log in to developer.adobe.com and create a new Project. Projects are how the console organizes different integrations or client apps.
-
From the Project, add an API, and select Adobe Workfront. This API is under the Experience Cloud category. All Workfront APIs, including Planning, Workflow, and Review and Approvals, share this single API.
-
Select the Server-to-Server authentication option, then choose the correct instance if your IMS Org has more than one Workfront instance.
For guidance on choosing an authentication type, see Understand Adobe Developer Console authentication types in this article.
-
On the Project page, open the details of your new OAuth Server-to-Server credential to find your Client ID, Client Secret, and the information needed to generate access tokens.
-
Update your integration, script, or tool to authenticate with these new credentials in place of the old Workfront OAuth2 client ID and secret.
-
Confirm access in Workfront. Creating the API client automatically adds it as the Workfront user “
techacct”. By default, it’s added as a Contributor with limited access, but you can adjust its access level like you would for any other user. -
(Optional) To grant the
techacctuser administrator rights, add the Technical Account’s email as an administrator of the relevant Product Profile in Admin Console. -
Test the integration end-to-end.
-
Retire the old OAuth2 application entry in Workfront after you’ve confirmed the new connection is working.
For full step-by-step details and screenshots, see Gaining access in Adobe’s Developer Console documentation.
If you are not a System Administrator
You need to loop in your organization’s IMS Org administrator to complete the migration, since setting up the new credential in Adobe Developer Console requires that level of access. If you manage or maintain an integration but so know know who your organization’s IMS Org administrator is, contact one of the following:
- Your Workfront account team
- Your internal IT team
- Your engineering contact
If you don’t migrate
Integrations still using the legacy OAuth2 client ID/secret pattern after February 1, 2027 stop being able to authenticate against the Workfront API, and any dependent workflow, sync, or automation fails. There is no extension planned past this date, so migrate your integrations well ahead of it.
Frequently asked questions
Does this affect the packaged integrations Adobe provides, such as Slack or Microsoft Teams?
No. Adobe-managed global applications are being migrated by Adobe directly and don’t require action on your part.
Will my existing integration stop working before February 1, 2027?
No. Existing custom OAuth2 applications continue to function normally through February 1, 2027. Only the ability to create new custom OAuth2 applications is affected, starting November 1, 2026.
Is there a cost to migrating?
No, there is no additional cost associated with authenticating through Adobe Developer Console.
Where can I get help?
Reach out to your Workfront account team or open a support case if you have questions about your specific integration or timeline. For the official, up-to-date setup walkthrough with screenshots, see Gaining access in Adobe’s Developer Console documentation.