Handling Refresh tokens(Schedule strategy) for Azure AD generic namespace.

In OIDC Generic security namespace , there is an option to use Refresh tokens as a scheduling strategy instead of using the password flow.

When this approach is used , refresh tokens will be used for getting an access token when the schedule runs/authenticates.

In some providers like OKTA , there is an option to set the expiry of the refresh token to unlimited ,

so that you can continue to use the refresh token indefinitely and do not have to ask the user to login once the schedule is created.

However for Azure AD , Refresh token implementation is a little different.

Every time a non interactive login is used (Like schedules) , the refresh token that is used to get access token , also gets a renewed refresh token.

Microsoft does not guarantee on the expiry of the old refresh token , and their recommendation is to discard the old refresh token that is used in the request and persist the new renewed refresh token in the application.

As per Microsoft there is no guarantee on the expiry of the old refresh token as the guidance is to use the renewed refresh token on every request.

Also as per RFC for oauth2 , recommendation is to use the new refresh token on every request.

https://tools.ietf.org/html/rfc6749#section-6

The current implementation for scheduling does not persist any new refresh token that is returned on the schedule run ,

but it keeps using the first ever refresh token that was created until the token expires.

User has to manually login and renew the credential to get a new refresh token after it expires.

This causes interruption in scheduled activity , and also nulls the purpose of implementing refresh tokens at the first place.

So the request is :

If a new refresh token is returned(Like in azure ad) then persist it in cognos .

If the new refresh token is not returned(Like in okta) then keep using the existing refresh token until it expires.