Related
Recommended
Imran Aziz

*Please note this development has now been put on hold until later on in the year. Token expiration will continue to work as it does today. We will advise all our API clients and give notice prior to development work starting on this. We apologise for any inconvenience this may have caused *

From Collaborate version 4.4 the option to set access token expiration for three months, six months or a year has been removed. The reasons for this are to avoid situations where an access token and refresh token both expire at the same time and also because access tokens become less secure the longer expiration they have. 

The maximum the access token can be set from version 4.4 is one month. Any existing API tokens configured to expire after a month will expire and the access token configuration for API application registration will be reset to expire after a month. 

An API client who has already coded the OAuth workflow correctly should have no problem with this change as the refresh token should be used to obtain the access token on expiration. Any API clients who have not coded the refresh token workflow will need to implement the refresh token workflow or manually generate the access token to allow their application to continue working. 

Please let us know if you have any concerns about this change. 

  • Thomson Reuters Thomson Reuters staff member

    Hi Andrew Quinn - please see our updated post above. This development has now been put on hold and we will keep you posted once anything changes.

  •

    Andrew Quinn thank you for the prompt feedback I am going to discuss this internally to make sure that our API clients are not disrupted by this change. If there are any changes to what has been communicated they will be shared in the Developer Community.

  •

    Hi Imran Aziz,

    I'd like to throw my hat into the ring first.  I don't have concerns as to the why, but I do have concerns as to the when.  With approx. 4wks to 4.4 being released, I feel that this change hasn't been communicated in a time relative to it's impact.

    We utilise AWS Lambda's to run micro-services, using the Collaborate API.  Lambda's by themselves do not have the capabilities for persistent storage - for that we'd need to leverage off S3 or DynamoDB, for example.  We chose to adopt the manual token approach initially, to satisfy project timescales at the time, and to produce lean and efficient microservices.  Now will need to rearchitect our services to gain persistent storage and use the refresh token mechanism, as well as factor this into our current deadlines - this was always to be a design decision to come back to, but one that we could factor into our long-term project timelines.

    I also would like to ask how this impacts the Neota/Raven/Kira etc integrations? From what I remember of seeing the Neota prototype - I could be wrong here, or things have changed - it relied on a configured authenticated token.  I don't remember seeing a refresh mechanism?  Many of these integrations will be built from simple automated script-like interfaces, where again persisted storage has not been factored in.

    Thanks in advance, Andrew