Not Considering

Hi James,

If you have registered a valid application then an initial authentication flow (requiring username and password) will return an access-token (valid for 20 minutes) and a refresh-token (valid for 90 days). The refresh-token can be exchanged for a new access-token and refresh-token without supplying the username and password and without concern for an expired password. This is standard OAuth2. Increasing the lifetime of an access token increases the risk of a compromised token being used to access data.

A persistent token (i.e. with no expiration) would be a security flaw in the application and is not something that we would be prepared to implement.

I hope this helps to move you forward with your integrations.


Separate API user password expiration from human user password expiration.

We have numerous API integrations (MindTouch Knowledge Base, Tridion Sites, GitHub, etc) that have a TMS "user" associated with them.

TMS has a mandatory 90-day password expiration/reset requirement, which is useful for getting the human users to change their password periodically.

It can be turned off, but that would turn it off for all users, not just the API "users".

But could that be separated for the API users? Unless we preemptively change the API users' passwords on that schedule, the integrations break.

For example, our Google implementation has a single token that we provide that never expires, and we don’t have to refresh.

Perhaps this product enhancement could include:

  • Token timeout increase (2-3 hours)
  • Only providing a token instead of four credentials.
  • No password reset after 90 days, or preferably just require that the token can persist.

Thanks for considering this enhancement!

  • Hi David,

    Thanks for the info. Does the SDL-built integration for Sites & TMS use this method? We get hit with the 90 day password reset problem for them too.

    Do we not have that integration configured correctly, in order to take advantage of this method?

    Thanks again, James