We have a requirement to onboard an application called Seismic using a Web Service connector in SailPoint IdentityIQ. Currently, we are facing a challenge where the refresh token expires after a certain period, requiring manual intervention to replace the old token with a new one.
Our goal is to eliminate manual dependency and automate the refresh token generation process using the authorization code flow.
Is it feasible to implement this through custom authentication in SailPoint IIQ. If yes, could anyone provide your suggestions and help to achieve this usecase.
One way could be - to create a Task which runs a Rule in backend and the logic for that Rule will be to get Token and update in Application object.
This task can be scheduled to run in sync with Token expiry time. For eg: if token expires every 1 hr then this task could be scheduled to run every 1 hr.
We have a very similar scenario and its working for us.
Your question is “generate a NEW refresh token using Authorization Code flow” (i.e., re-consent). That flow is interactive by design (browser login + consent), so IIQ can’t fully automate refresh-token creation internally without an external component to handle the user consent step.
What IIQ can do reliably:
Generate the refresh token once (manual auth-code consent) and store it in the Web Services application config.
Configure Web Services connector to use OAuth2 + Refresh Token grant so IIQ automatically gets new access tokens when needed.
If your token endpoint returns a rotated refresh_token along with access_token, IIQ Web Services connector can save the updated refresh token automatically.
If the refresh token truly expires/revokes and the provider requires a brand-new auth-code consent, then it must be manually generated and updated (unless you build an external “token broker” to do the consent flow and then update IIQ).
About the suggestion to “schedule a task every hour”: that approach is fine for refreshing access tokens, but it doesn’t solve refresh-token expiration that requires new user consent.
please remove the old token from application.xml via afterprovisioning rule after requested operation successfully. then whenever you are calling any operation it will generate the new token and update in the xml.
before calling the token generation api please check if old token is available in applciation.xml or not. if yes then remove the old token and proceed to call the token generation api.