Description - Workfront's API does not use the default standard for OAuth2 Authorization Code Flow. Using out-of-the-box tools available in Integration Platforms or Microsoft Power Platform or other web frameworks is not possible because these solutions expect OAuth2 Authorization Code Flow to use access_token as a Bearer token returned via the and not as sessionID.
Why is this feature important to you - There is an increase in development cost and maintenance when creating or connecting third-party apps to Workfront via the Workfront API because of the non-standard OAuth implementation. Limits or even prevents our ability to continue orchestrating and automating work by placing Workfront at the center of our operations.
How would you like the feature to work - Ultimately, we would like to be able to use the access_token as part of the Authorization Header as a Bearer token described in the OAuth and standards documentation. This would mean that the token_type be set to Bearer (default, industry standard) and not sessionID (custom Workfront, non-standard) and for subsequent API calls to handle this appropriately.
OAuth 2.0 Bearer Token Usage
RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage (ietf.org)
Current Behaviour - Workfront’s OAuth API implementation is non-standard, in that once you’ve gone through the usual Authorization Code Flow, the access_token needs to go in the Request Header “sessionID” in each API call. This non-standard approach makes it very difficult and sometimes impossible to integrate with other third-party and custom built applications unless significant time is invested into workaround. In other cases we are left to use a fixed API Key, which isn’t ideal from a security perspective.
