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.

David

Sign in to vote on ideas
0
Sign in to vote on ideas

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!

  • 1 comment
  • 0 members are here