Why do specific Overloads of acquireToken(..) do not return refreshTokens?

[SErfkamp]

Hey,

Title is basically the questions.
Some overloads of acquireToken(..) do not return refreshTokens while others do.
For example if using ClientCredentials.

What is the expected behavior? Should we handle the token expiry ourselves and schedule a job that refreshes the AccessToken before it expires - or is there a different way to handle this?
I am not that experienced with auth/tokens in general.

Thanks for the input!

[sangonzal]

@SErfkamp This is expected behavior. Refresh tokens is an oauth artifact introduced to try and reduced the number of times that end users are being prompted and asked to grant permissions. For flows where the is no user involved (for example ClientCredentials, in which a token is issued to the application and not an user itself), having a refresh token provides no real value (Since there wouldn't be any difference in between using a refresh token to get a new access token, and just acquiring a new access token)

Although you could schedule a job, it is not necessary (This all depends on your application). You could just check if the access token is expired before using it, and if so, just acquire a new one, the same way in which you acquired the one that is expired.

[sangonzal]

Also I would recommend you take a look at MSAL, a new library that builds on ADAL and adds a lot of great features. Although ADAL is not being deprecated, we will not add any more features to it going forward.

[SErfkamp]

Thanks a lot for the explanation. It is clear now and does make a lot of sense. Feel free to close this issue!

I was confused as I was assuming that a refresh token was best practice, because it could be leaner or maybe because credentials must not be sent again - but it seems it is only thought for User-Interaction.