1

I'm using MSAL for B2C with Android and it I have been following this example. When first logging on I use #1 acquire token / run user flow and #3 Acquire token silently when I need to call an API and my token has expired.

The silent token seems to map to Access & ID token lifetimes (minutes) in the Azure Portal. enter image description here

The user flow for susi seems to map to Lifetime length (days) in the portal: enter image description here

I think the 90 days are up, so what do I do to refresh that token and how do I tell if I'm close to the 90 days?

Maybe I'm not understanding this completely.

UPDATE

Ok, I saw the response below which was helpful, but I don't know if or how my use case can be achieved given the information provided.

Here is the use case: I have an app which can be used in disconnected mode, and frequently is, on a shared device. The app does need to be connected to be downloaded and for user registration on the device. When the device is connected it also sends data to the cloud, but otherwise stores it locally. When sending data to the cloud it needs to have a silent refresh of the token.

All of this has been working until the 90 days are hit and I need to re-authenticate. This would be a good policy but given the disconnected nature of the app I would like to start asking the user using a snackbar as the countdown gets closer. According to the response there is now way to determine the 90 expiration, and I have seen this as the profile.getExpiresOn() seems to hold the expiration date of the access token (the 60 minute one) and reverts to the date the profile was created when the 90 day one runs out. At least I think that is what is happening. I wish I had access to both dates but guess I don't and that's what I think was confirmed below.

Does anybody else have a use case like this? It seems like it might not be so uncommon and can see the need for the 90 day token expiration date.

lcj
  • 1,355
  • 16
  • 37

1 Answers1

0

In order to completely understand this you need to understand the difference between below settings and what these settings mean.

Refresh token lifetime is by default 14 days, which means you can redeem the refresh token within 14 days of its issuance. When you redeem the Refresh token, a new Access, ID, and Refresh token pair is issued. The new refresh token is again valid for 14 days.

  • If you have Refresh token sliding window lifetime set to bounded and the Lifetime length is 90 days, users will be required to re-authenticate regardless of when the most recent Refresh token was issued.

  • If you have Refresh token sliding window lifetime set to no expiry, the Lifetime length will not be configurable any more. In this case, if the refresh token is redeemed within every 14 days (configured in Refresh token lifetime), users will never have to re-authenticate.

If you don't want to force the users to reauthenticate after 90 days, you can either set Lifetime length to its maximum value of 365 days or set Refresh token sliding window lifetime to no expiry.

You will not get any notification before expiry of the refresh token. However, you can check signInSessionsValidFromDateTime property via Graph API or refreshTokensValidFromDateTime via PowerShell to see when the refresh token was last issued to the user.

AmanpreetSingh_msft
  • 605
  • 5
  • 8
  • So I can either create code to re-authenticate and leave the settings as they are or set the "Refresh token sliding window lifetime" to "No expiry", correct? What if the user tries to access an API beyond the 14 days? Do I need them to re-authenticate anyway? – lcj Sep 18 '21 at 14:47
  • Yes, that is correct. If the user tries to access an API beyond the 14 days, refresh token will be expired and interactive authentication will be required to acquire the new refresh token. – AmanpreetSingh_msft Sep 20 '21 at 09:13