Expose refresh token in MSAL

[mpbiehn]

Core Library

MSAL.js v2 (@azure/msal-browser)

Wrapper Library

MSAL React (@azure/msal-react)

Public or Confidential Client?

Public

Description

After trying to figure out how to get access to the refresh token in msal-react I came across a few issues and documentation that the refresh token isn't exposed. One consideration for exposing the refresh token is using it to provide a biometric login option within our Cordova Hybrid app. Today we store the refresh token on the device (encrypting it with a biometric challenge) as part of our biometric login flow. Sure would love to have access to the refresh token, unless there's another way to solve this problem that I'm not aware of.

Source

External (Customer)

[tnorling]

@mpbiehn We intentionally do not expose the refresh token on our API surface, and are not likely to change that stance as we are actively working on features which would further protect the refresh token by not returning it to MSAL.js at all. Can you please go into more detail about why biometric login in Cordova requires an RT?

[mpbiehn]

@tnorling sure, today we aren't using MSAL (msal-react) but would like to soon as part of our Singe Page Application. At a high level, here's what our biometric login flow looks like:

• We leverage two Cordova plugins as part of our hybrid Single Page Application, Fingerprint All-In-One and Secure Storage

• Refresh access token documentation that we referenced during initial development on how to refresh the access token

• After first successful login, we present the user an option to login biometrically (face, fingerprint, etc.) based on their device capabilities. If they select the biometric option we use Fingerprint to handle the biometric authentication then use Secure Storage to save the refresh token. We also are sure to update refresh token using Secure Storage after each successful login.

• At next login, if the user selects "biometric" login versus default login (username,password), we use Fingerprint to handle the biometric authentication, upon success we get the previously saved refresh token using SecureStorage and call the /token endpoint passing the refresh_token vs code to refresh/renew the access token.

Here's another article that might explain it better - https://developer.okta.com/docs/guides/unlock-mobile-app-with-biometrics/android/main/.

I'm open to other options on how to handle biometric login, just haven't found a better option yet.

If MSAL doesn't return the refresh token at all in the future, how will MSAL handle refreshing the access token? Doesn't the current version of MSAL use the refresh token (in the background) to do this?

[tnorling]

There's potentially a bigger issue here than just returning refresh tokens. We do not currently support custom storage solutions (i.e. SecureStorage), which means, if I'm understanding your scenario correctly, you would be storing tokens in SecureStorage in addition to the storage used by MSAL.js (local or session storage). If that's the case, I'm not sure I see the value in using SecureStorage at all until we do support custom storage (we do have an item in the backlog to look into this).

Furthermore, it sounds like the biometric sign-in doesn't actually require that it return a refresh token but rather just unlocks access to SecureStorage. Do I understand that correctly? If so, once MSAL.js supports custom storage the pattern I would suggest is to unlock SecureStorage and then use the MSAL APIs to acquire an access token - letting MSAL.js reach into SecureStorage and retrieve what it needs. I don't see a reason why your application would need to be aware of the implementation details of acquiring access tokens (getting a refresh token and calling the /token endpoint with it), that is after all what an authentication library like MSAL.js is designed to abstract away from you.

[mpbiehn]

@tnorling thanks for the quick response. I'm a big fan of MSAL abstracting authentication, big reason why we'd like to use it within our app. :)

You are correct in that biometric sign-in unlocks access to SecureStorage. Today, we aren't using MSAL so we are storing the refresh token in SecureStorage. Was thinking of following a similar pattern (not knowing any better) with MSAL but doesn't sounds like that is possible (no refresh token available) in the current version.

To be sure I understand your suggested pattern, are you saying once MSAL.js supports custom storage, we would leverage the custom storage vs local or session storage? And we'd leverage MSAL APIs (getting what it needs from the custom storage) to acquire an access token? Any ETA on the backlog item for custom storage or somehow I could follow the progress on this backlog item?

Also, any thoughts on how to handle biometric login with MSAL until custom storage is available? This might hold us up from using MSAL. :(

[tnorling]

You can track progress on custom storage in issue #1588, I unfortunately don't know right now when it will be prioritized.

To be sure I understand your suggested pattern, are you saying once MSAL.js supports custom storage, we would leverage the custom storage vs local or session storage? And we'd leverage MSAL APIs (getting what it needs from the custom storage) to acquire an access token?

That's correct. We haven't really sat down to design the feature yet but I imagine we would expose some sort of cache interface for you to provide implementations of cache getters and setters, which MSAL.js would then use instead of localStorage and sessionStorage for all cache operations.

Also, any thoughts on how to handle biometric login with MSAL until custom storage is available? This might hold us up from using MSAL. :(

I wish I could give you a better answer but unfortunately we don't have any explicit support for Cordova or any other hybrid frameworks at the moment. So while you could try to come up with some sort of workaround in the meantime, it would likely require doing some things we wouldn't endorse and we would not be able to offer much help if you run into issues :/

[mpbiehn]

@tnorling thank you for your quick responses, much appreciated!

[tnorling]

@mpbiehn My pleasure! I'm going to go ahead and close this issue but you can track #1588 for news on custom storage.