Shorter refreshToken lifetimes for improved security

[devinrhode2]

Core Library

MSAL.js (@azure/msal-browser)

Wrapper Library

MSAL React (@azure/msal-react)

Public or Confidential Client?

Public

Documentation Location

https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/token-lifetimes.md#token-lifetimes-and-expiration

Description

Calling acquireTokenSilent with forceRefresh: true and refreshTokenExpirationOffsetSeconds set to 15 minutes results in exp set to 2.5 hrs, but I would have expected this to be 15 minutes.

I see accessTokens can be configured down to 10 minutes:
https://learn.microsoft.com/en-us/entra/identity-platform/configurable-token-lifetimes#access-id-and-saml2-token-lifetime-policy-properties

But here, I read that, if you have a refreshToken, you essentially have an accessToken: https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/token-lifetimes.md#refresh-tokens

(I am therefore unsure what purpose a refreshToken serves in terms of security. Under what circumstances can a non-expired refreshToken not be used to get an accessToken? I suppose an accessToken could be stolen by an actor inspecting http headers, and that actor doesnt necessarily have a refreshToken, and further, if everything goes right, even if that actor got the refreshToken, they can't simply redeem that refreshToken for a new accessToken... because they are missing some values from session/localStorage, which only the client has..... Is this correct?)

My goal is to figure out how to set an idle time of, say, 30 minutes, where a client's tokens will no longer be valid, and interaction would be required to resume session. To keep a session active without bothering the user too much, we would call acquireTokenSilent with forceRefresh: true when a user goes idle, and 5 minutes before the expiration time. To get new tokens our js would need to validate the microsoft session is still active. If a user independently logged out of Microsoft, they would have to log back in to get new tokens.

[tnorling]

refreshTokenExpirationOffsetSeconds set to 15 minutes results in exp set to 2.5 hrs, but I would have expected this to be 15 minutes.

This configuration does not control RT expiration. This controls at what point we will attempt to get a new RT. Setting it to 15 minutes means, "when the RT is expired or will expire in 15 minutes, try to get a new one". This is useful for scenarios where you want to ensure a user's session will not be interrupted with a login prompt for some minimum amount of time.

I suppose an accessToken could be stolen by an actor inspecting http headers, and that actor doesnt necessarily have a refreshToken, and further, if everything goes right, even if that actor got the refreshToken, they can't simply redeem that refreshToken for a new accessToken... because they are missing some values from session/localStorage, which only the client has..... Is this correct?

If a malicious actor gains access to your refresh token they can use it to mint new access tokens until the RT expires. You must ensure your application is not susceptible to XSS based attacks that might expose the RT to an unauthorized party.

[devinrhode2]

Is it possible to configure refreshTokens to expire in less than 24hrs?

[tnorling]

Not directly, no, but you can configure conditional access policies to force reauthentication more frequently