acquireTokenPopup flow suggested behavior

[jonocairns]

Core Library

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

Wrapper Library

Not Applicable

Public or Confidential Client?

Public

Description

When using the recommended flow stated in the documentation for token acquisition, there's a two-step approach calling acquireTokenSilent and then acquireTokenPopup if InteractionRequiredAuthError is thrown.

My main problem involves acquireTokenPopup not handling multiple requests

My suggestions would be as follows:
acquireTokenPopup should internally store the initial promise for the popup and return that for all subsequent requests, till the initial promise has been resolved

My reasoning is as follows:
Since this code path is used for token acquisition and UI's tend to make multiple API requests at the same time, it's reasonable to assume this is not an edge case and should operate similarly to how acquireTokenSilent handles multiple requests.

This is how our acquireToken function looks with a workaround:

    async acquireToken(): Promise<string | any> {
        const clientApplication = this.getPCA();
       
        const tokenRequest = {
            account: this.user,
            scopes: this.config.scopes
        };
        try {
            const authResponse = await clientApplication.acquireTokenSilent(tokenRequest);
            return authResponse.accessToken;
        } catch (err) {
            try {
                if (err instanceof InteractionRequiredAuthError) {
                    if (this.inflightAcquireTokenPopup) {
                        console.info(
                            'inflight acquireTokenPopup request already taking place... waiting for that response'
                        );
                        const resp = await this.inflightAcquireTokenPopup;
                        return resp.accessToken;
                    } else {
                        this.inflightAcquireTokenPopup = clientApplication.acquireTokenPopup(tokenRequest);

                        const tokenPopupResponse = await this.inflightAcquireTokenPopup;
                        this.inflightAcquireTokenPopup = null;
                        return tokenPopupResponse.accessToken;
                    }
                } else {
                    console.error(err);
                }
            } catch (ex) {
                console.error(ex);
            }
        }
    }

Thanks!

Source

External (Customer)

[sameerag]

@jonocairns Thanks for reaching out. For popups or any interactive requests, we need to open a popup or reload the browser window to handle the response from the service. Having requests queued up may result in UX experience degradation.

However, can you elaborate your scenario where you would need popup requests simultaneously?

[jonocairns]

Hey @sameerag - thanks for responding! 🥳

I think it's less about queuing and more about coordination between inflight requests and subsequent requests for a token, essentially minimizing the interaction_in_progress chances when a burst of API requests are fired in quick succession.

My scenario is this:

1. login to app on a Friday, continue working, and leave logged in over the weekend
2. access app on a Monday, click to navigate to a new page
3. the new page fires multiple API requests that require a token

actual result: the first API request triggers the popup, and all subsequent requests fail with an 'interaction_in_progress' error. We display errors in toast notifications so we get unauthenticated errors displayed in the UI for these requests.
expected: the first API request triggers the popup and all subsequent requests while the first is still in flight are directed to await that first interaction (I think this is similar to how acquireTokenSilent operates under the hood when refreshing the token).

Since popups still keep the UI active while auth is happening I think this would be a rather common use case where more than one API request requiring a token was in flight, and it could follow the same pattern used by acquireTokenSilent (if indeed this is used) - it'd be great to get this same capability for acquireTokenPopup.

Right now I'm manually handling this with the code sample above. I store the inflight request temporarily - if it exists then I direct new token requests to wait for that promise to complete, otherwise, I store/await/clear/return the first request.

[sameerag]

@jonocairns We can consider this as a feature for future use but for now the guidance is to avoid concurrent interactions in your code. However this would require some design work and I cannot promise the prioritization considering the other work items currently in progress.

Thanks for bringing this to our attention.