0

While trying to find a way to maximize the time before a user has to do a reauthentication (especially in cases when the user does a social login, e.g. sign in with microsoft).

I have stumbled upon this microsoft documentation which states token lifetimes.

Microsoft docs - token lifetimes

As well as these MSAL docs (which is the library that I use on my web application)

MSAL docs - token lifetimes

Both of these sources state limitations I have found to be not true:

Microsoft docs

token_lifetime_secs - Access token lifetimes (seconds). The default is 3,600 (1 hour). The minimum is 300 (5 minutes). The maximum is 86,400 (24 hours).

I have found that while uploading the B2C policy there is a validation which states the following.

The access token lifetime should be between 5 minutes and 10080 minutes B2C validation regarding access_token lifetime in the JwtIssuer TP

Setting this up, issuing a B2C token as a part of a SPA login flow I was able to decode an access_token which has a lifetime of 7 days until moment of issue

Decoded access token claims showing that expiry date is 7 days from moment of issue

This conflicts with the Microsoft docs that the access_token lifetime is limited to 24 hours.

Does anyone have experience with this, what is the real lifetime of the access token?

If I store this access_token in local storage will the user have a persisted session for the next 7 days? Because as I understand from the MSAL docs, as long as the access_token is not expired, a refresh_token will not be used (this refresh_token has a lifetime of 24h non-extendable, and independent on how many refreshes were done previously) and thus the user will maintain access to the app of 7 days without the need to reauthenticate.

How does the B2C custom policy session lifetime come into play here?

What is the relationship of the custom policy session lifetime to the access token and MSAL?

milorad
  • 121
  • 2
  • 12

2 Answers2

1

As per this:

"Access & ID token lifetimes (minutes) - The lifetime of the OAuth 2.0 bearer token used to gain access to a protected resource. The default is 60 minutes. The minimum (inclusive) is 5 minutes. The maximum (inclusive) is 1440 minutes."

And as per this, SPA are a special case. Are you using PKCE?

Also, has the configuration of token lifetimes been changed?

rbrayb
  • 46,440
  • 34
  • 114
  • 174
  • My app registration on B2C is eligible for Authorization code flow with PKCE, on the react app I have followed [MSAL docs](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/acquire-token.md) (in short, acquireTokenSilent - here I use forceRefresh, in order to be sure to go to B2C and not retrieve the token from cache - and if it fails with InteractionRequired then invoke acquireTokenRedirect. – milorad Jun 17 '22 at 07:56
  • As for the token lifetimes configuration I have changed the JwtIssuer technical profile in my signInSignUp custom policy, so that it has the maximum values that the B2C custom policy validator allows (as noted above, this is more than what the Microsoft docs suggest). The values are following: token_lifetime_secs = 604800 seconds (7 days), id_token_lifetime_secs = 604800 seconds (7 days), refresh_token_lifetime_secs = 7776000 seconds (90 days). I could confirm that the token_lifetime_secs is indeed 7 days as noted above in the decoded token's exp claim. – milorad Jun 17 '22 at 08:06
  • If it is relevant, my RelyingParty has a SessionExpiryInSeconds = 86400 seconds (24 hours), and the SessionExpiryType = Rolling, I am not sure how this reflects on MSALs behavior and also on the access_token lifetime. As I understood this session controls the cookie lifetime and provides a last resort for MSAL when both access_token and refresh_token have expired, though I am not sure on this point. – milorad Jun 17 '22 at 08:09
1

I had the exact same experience and created an issue on the GitHub documentation page: https://github.com/MicrosoftDocs/azure-docs/issues/109838

Frederic
  • 633
  • 5
  • 12