ISC: Expiry of "external triggers" tokens generated by /oauth/token is 68 years

Feedback Bugs
,
1

What problem are you observing?

The HTTP answer from the https://tenant.api.identitynow.com/oauth/token?grant_type=client_credentials has the attribute expires_in set to 2147483646.
According to Authentication | SailPoint Developer Community

The expires_in value describes the lifetime, in seconds, of the access_token

This means the token expires in 68 years.

The JWT access_token (when decoded) contains a similar long exp:

image
image894Ă—62 9.32 KB

I think that either

  • the values presented are incorrect (and the actual expiration is much shorter)
  • or the value is way too long from a standard security practice

What is the correct behavior?

The expiration token should be shorter. Colin mentions something about 30 days here: Implementing A Request Response Type Trigger in Workflows

This will produce an access_token that expires every 30 days.

His access token had the same large expires_in return value:

image
image1033Ă—344 32.7 KB

What product feature is this related to?

Generating access tokens for ISC.

What are the steps to reproduce the issue?

From Colin’s post:

  • Start by creating a new workflow that is triggered by an external trigger. Click the “New Access Token” button to get the client credentials used to authenticate to the workflow
  • Use the command presented in the UI: curl -H "Authorization: Basic NzU...." -X POST "https://tenant.api.identitynow.com/oauth/token?grant_type=client_credentials"
  • Check the expires_in. Check the exp from the access_token on jwt.io.

Do you have any other information about your environment that may help?

No.

2

The token expiration time for external triggers is much longer than for PATs (12 hours). The external trigger token itself is specifically limited and purpose built for triggering the workflow and that workflow alone. The token cannot be used for anything else. We made a decision to set the timeout far into the future to prevent failed workflows as it was deemed extremely low risk. This allows the admins to control token rotation on their schedule. This is important because once the token is rotated/regenerated, the former token is invalidated. Thus the admins control the rotation on their schedule and invalidate the tokens when a new one is generated avoiding failed workflow executions.

As for my blog post, it looks like it’s outdated and I need to update it. I must have incorrectly assumed the expiration was in milliseconds instead of seconds. The good news is that you won’t need that second workflow to refresh the token since it effectively doesn’t expire.

1 Like
3

I have updated my blog post accordingly. FYI @adamian , you could use these steps listed here to implement a more frequent token rotation schedule if you wanted to.

4

Thanks for the clarification, @colin_mckibben . I thought it was an error as 2147483646 = 2**31, so it looked more like a placeholder than a value which was specifically settled upon.

1 Like