Rotating Refresh Tokens

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hi,

We are trying to integrate a System with the WebServices Direct connector. We are authenticating on this system using OAuth2.0, but the system uses a rotating Refresh Token, for example, this is the steps to get a new Access Token:

1 - Make a call using the Refresh Token with the body:

{
    "grant_type": "refresh_token",
    "client_id": "CLIENT_ID",
    "client_secret": "CLIENT_SECRET",
    "refresh_token": "REFRESH_TOKEN"
}

This request return to us a new Access Token and a new Refresh Token, the Refresh token that we use to get this response becomes invalid.

2 - To get a new AccessToken we need to make a call using the new returning Refresh Token from the call above, here are some example of the response returned:

{
    "access_token": "TOKEN",
    "refresh_token": "v1.asokdaoskdoaskdoaskdckcckkckckckckckckc1DDDDS", -- New Refresh Token that we should use to get a new Access Token on the next call.
    "scope": "read",
    "expires_in": 3600,
    "token_type": "Bearer"
}

Has any one have an idea on how could I configure this on IDN? I know that i can use the Custom Authentication on the Web Service connector, but I could not identify a solution for this.

Regards,

2

image
image1920×667 76.3 KB

Check NOTE part, this should be supported OOTB.

3

Hello Chirag,

Thanks for the response, I’ve made some tests and once the first Refresh Token it’s used, the connector did not uses the new one and I receive the following error.

image
image1455×71 11.3 KB

Could you send me the link of this documentation that you are looking at?

Regards,

4

This is interesting because we are configuring refresh_token grant in JIRA integration and we are having similar problem. The first refresh token is used but the subsequent calls fail after access token expires.

I have personally not used refresh_token grant type in webservices but I was just assuming the documentation is correct.

I am referring this doc: https://community.sailpoint.com/t5/IdentityNow-Connectors/Web-Services-Source-Configuration-Reference-Guide/ta-p/78511

5

We are trying to integrate JIRA as well with the WebServices connector, but no luck using the refresh token.

I’ll take a look into this document to see if has any additional configuration.

6

There is no additional configuration needed in JIRA integration which I made and I have created support ticket for them to look into. You can also raise same with them so they have more customers reporting the issue.

7

Thanks for the information Chirag, I’ll raise a ticket ass well.

8

Hi Felipe,

I have given these steps to Chirag in a separate support ticket, so I figured I’d post this here as well:

What you are reporting is actually a known issue to the connector team and our services team as well. Currently, the integration code for the JIRA SDIM integration does not currently support the rotating refresh token structure which Atlassian is now requiring for OAuth2.0 authorization. This has to do with this following linked article speaking to persistent refresh token being deprecated: Superseded: 31 January 2022 - Action required - Deprecating persistent refresh tokens.

This is something the connector team will need to do some research on, and then will provide a fix in an upcoming connector bundle release.

As this will take some time before this is fully supported, here are alternative steps to try:

  1. You actually can still use Basic Auth for authentication as one alternative
  2. If you create an application-specific API token via the Atlassian account (after logging in), that token can be used as the password in conjunction with the username of the user that you’re logged in as.
  3. Previous steps our services team have taken to achieve this::
  4. Created the OAuth2.0 Atlassian app client with offline_access scope as normal.
  5. Generated a refresh token using the initial refresh token provided through the Authorization URL. The expires_in interval returned from that refresh token was 3600 seconds (1 hour).
  6. Waited just under two hours just to be safe, and re-requested a new refresh token using the previously obtained refresh token that should have been expired. This still returned a successful response with a newly minted token with, again, a 3600 second expiry.
  7. This should work based on the 90-day expiry interval for inactive tokens as described in the Atlassian documenation: OAuth 2.0 (3LO) for apps.
  8. This has been tested in dev tenants previously and it worked without issue – you do have to wait a minute or two to let the updated integration config get passed down to the VA before testing, but after an initial false-positive, my testing allowed authentication in this manner.

For any further assistance with the steps outlined above, you can engage our Expert Services team who would be happy to assist. As the steps provided above are a solution provided by them, they would be able to help with this process going forward should you run into any further issues during configuration. This would not be something support can assist with.

For updates on this upcoming release, I would ensure you’re subscribed to connectivity updates from our Compass site. Or, you can reach out to your CSM directly to ask for an ETA on when this release is expected and they can get back to you from the connector team and/or PM as well. Thanks!

9

Hi Chris,

Thank you for the clarification on this case, i think we will follow with the Basic Auth for now.

And wait for the new connector release.

Regards,

1 Like