As an Adobe Workfront administrator, you can create OAuth2 applications for your instance of Workfront, which allow other applications to access Workfront. Your users can then give permission to those other applications to access their Workfront data. In this way, you can integrate with applications of your choice, including your own in-house applications.
When you create an OAuth2 application, you generate a Client ID and Client Secret. Your users can then use the Client ID in API calls to integrate with the application you have created.
In the context of OAuth2, “creating an app” refers to the process of creating this sort of access link between an app and a server such as Workfront.
You must have the following access to perform the steps in this article:
Adobe Workfront plan* | Pro or higher |
Adobe Workfront license* | Plan |
Access level configurations* | You must be a Workfront administrator. |
*To find out what plan, license type, or access you have, contact your Workfront administrator.
Imagine that an application needs to pull some specific information from Workfront. An application that requests information is called a client. For this example, the client name is ClientApp. ClientApp needs access to a particular user’s information, and therefore needs to access Workfront as that user. If your user gives ClientApp their username and password, ClientApp could access all of the data that the user can access. This is a security risk, because ClientApp only needs a small, specific set of information.
When you create an OAuth2 app for ClientApp, you are essentially telling Workfront that ClientApp is allowed to access Workfront, but only if the user whose account ClientApp is accessing gives permission for the access.
When creating an OAuth2 application, choose the type of application that best meets the needs of your integration.
Application type | Best for | Authentication method |
---|---|---|
Machine to Machine Application |
Best for CLIs, daemons, or scripts running on your server Examples:
|
Authentication through JSON Web Token with public/private key-pair encoding. |
Single Page Web Application |
Best for mobile or single-page web applications Examples:
|
Authentication through OAuth 2.0 Authorization Code flow with Proof Key for Code Exchange (PKCE). |
Web Application |
Best for server-side applications that handle credentials and tokens on the server Examples:
|
Authentication through OAuth 2.0 Authorization Code flow. |
You can have up to ten OAuth2 Applications total at a time.
Click the Main Menu icon in the upper-right corner of Adobe Workfront, then click Setup
.
In the left navigation panel, click System, then select OAuth Applications.
Click Create app integration.
In the window that appears, select Server Authentication.
Enter a name for the new application, such as “Workfront for ClientApp.”
Click Create.
Fill in the fields for the new app.
Client ID | This field is automatically generated. |
Client secret | This field is automatically generated IMPORTANT: Copy the contents of this field to another secure file before you close this page. You will not be able to see this secret key again. If you lose this key, delete it and create a new Client Secret.
|
Public Keys | Server to server apps use public and private keys for authentication. Do one of the following:
|
Name | This is the same name that you gave the app. This field cannot be empty. |
Description | Enter a description for the integration. |
Click Save.
For instructions on configuring and using the OAuth2 application with user credentials (authorization code flow), see Configure and use your organization’s custom OAuth 2 applications using JWT flow.
Click the Main Menu icon in the upper-right corner of Adobe Workfront, then click Setup
.
In the left navigation panel, click System, then select OAuth Applications.
Click Create app integration.
In the window that apears, select User Authentication.
Enter a name for the new OAuth2 application, such as “Workfront for ClientApp.”
Click Create.
Fill in the fields for the new app.
Client ID | This field is automatically generated. |
Client secret | This field is automatically generated IMPORTANT: Copy the contents of this field to another secure file before you close this page. You will not be able to see this secret key again. If you lose this key, delete it and create a new Client Secret.
|
Redirect URLs | Users will be redirected to this path after they have authenticated with Workfront. |
Refresh token rotation | Enable this option to issue a new refresh token whenever the refresh token is used. Your application must store the new refresh token after every refresh. |
Absolute refresh token expiration | Select the amount of time you wish a refresh token to exist before it expires. When it expires, your users must log in to the integration again. Select "No expiration" if you do not want the refresh token to expire. |
Inactivity refresh token expiration | Select the amount of time after which, if the user has not been active in your system, their refresh token expires. For example, if the inactivity refresh token expiration is 6 months, and the user does not log in for six months, the refresh token expires even though the absolute refresh token expiration may be set for longer. |
Logo | You can add a logo to make this app more identifiable. |
Name | This is the same name that you gave the app. This field cannot be empty. |
Description | Enter a description for the integration. |
App Description URL | This can be a link to an "About us" page or a page with more information about the integration. |
Click Save.
For instructions on configuring and using the OAuth2 application with user credentials (authorization code flow), see Configure and use your organization’s custom OAuth 2 applications using authorization code flow.
Click the Main Menu icon in the upper-right corner of Adobe Workfront, then click Setup
.
In the left navigation panel, click System, then select OAuth Applications.
Click Create app integration.
In the window that apears, select Single-page web application.
Enter a name for the new OAuth2 application, such as “Workfront for ClientApp.”
Click Create.
Fill in the fields for the new app.
Client ID | This field is automatically generated. |
Redirect URLs | Users will be redirected to this path after they have authenticated with Workfront. |
Refresh token rotation | Enable this option to issue a new refresh token whenever the refresh token is used. Your application must store the new refresh token after every refresh. |
Absolute refresh token expiration | Select the amount of time you wish a refresh token to exist before it expires. When it expires, your users must log in to the integration again. Select "No expiration" if you do not want the refresh token to expire. |
Inactivity refresh token expiration | Select the amount of time after which, if the user has not been active in your system, their refresh token expires. For example, if the inactivity refresh token expiration is 6 months, and the user does not log in for six months, the refresh token expires even though the absolute refresh token expiration may be set for longer. |
Logo | You can add a logo to make this app more identifiable. |
Name | This is the same name that you gave the app. This field cannot be empty. |
Description | Enter a description for the integration. |
App Description URL | This can be a link to an "About us" page or a page with more information about the integration. |
Click Save.
Further configuration and use of the created OAuth2 application requires some technical knowledge, including API calls.
Your users access the OAuth2 application through the API. This section describes the functionality in general terms, and is provided for information only.
For specific instructions on using the OAuth2 application, including specific API calls, see Configure and use your organization’s custom OAuth 2 applications using authorization code flow.
ClientApp needs some information from Workfront, so it sends a request to the Workfront API /authorize
endpoint. The request includes the response_type code
, which indicates that the request should return an authorization code.
This triggers Workfront to send an authentication prompt to the user. The user can enter their credentials into the prompt, which gives Workfront permission to communicate with ClientApp. If the user is already logged into Workfront, this step may be skipped.
The Workfront API sends an authorization code to ClientApp.
ClientApp sends the following information in a request to the Workfront API /token
endpoint:
If the authorization code and the client secret are correct, Workfront sends an access token to ClientApp. This access token is sent directly from Workfront to ClientApp, and cannot be viewed, copied, or used by any other user or client application.
ClientApp sends the access token to Workfront along with the specific request for information.
Because the access token is correct, Workfront sends the information to ClientApp.
For security, access tokens expire after a short amount of time. To get new access tokens without having to enter credentials every time, OAuth2 uses refresh tokens. Refresh tokens are stored by the client.
The process for acquiring a refresh token is the same as the procedure discussed in the section Authorizing with an authorization code and access token. The request for the authorization code includes the scope offline_access
, which indicates that the request should return a request token along with the authorization code.