[Identity] [Localhost to cloud] New browser credentials

[sadasant]

Thanks to customer feedback, we have identified that browser developers would benefit from a new authentication approach that matches more closely their experience.

Browser developers tend to work in localhost environments that are deployed to the cloud, and are more often than not involved with the authentication of users in web servers.

This issue is to tie up the development of a new set of features: two credentials specifically designed for browser developers. This credentials are initially called RedirectCredential and PopupCredential.

This issue discusses the current approach for browser developers, then highlights the current challenges, and finally describes how the two new credentials, RedirectCredential and PopupCredential, would solve these challenges.

If you want to try out how the new design looks in comparison to the old design, I’m working on mocked tests here:

• Mocked test with the current approach, the InteractiveBrowserCredential.
• Mocked test with the new approach, the RedirectCredential.

Current approach with InteractiveBrowserCredential

The current approach available for browser developers wanting to authenticate their end-users with Azure is to use the browser version of the InteractiveBrowserCredential. This credential uses the Authorization Code flow.

In principle, it's possible to use the InteractiveBrowserCredential from a browser as follows:

const clientId = "my-client-id";
const credential = new InteractiveBrowserCredential({
  clientId,
  // loginStyle: "redirect"
})

If no loginStyle is provided, this credential will use the popup login style.

If no loginStyle is provided, users are able to wait for the token using await, as follows:

const accessToken = await credential.getToken(scope);

This call will open a popup window, and after users finish the interactive flow, the promise will resolve with an access token.

The popup approach is not ideal because many browsers prevent popups from appearing. In those cases, users will need to manually enable popups before continuing to work with the browser app.

If users prefer to use the redirect approach, they will need to specify the loginStyle as redirect. When doing so, users will need to process the redirection on page load. The best way to do this at the moment is to initialize the credential and call to getToken on page load, as follows:

window.onload = async () => {
  const clientId = "my-client-id";
  const credential = new InteractiveBrowserCredential({
    clientId,
    // loginStyle: "redirect"
  })
  const accessToken = await credential.getToken(scope);
  // Once they have a token, silent authentication will work in the rest of the app.
}

Once they have a token, silent authentication will work in the rest of the application.

The credential is able to authenticate using the received code from the redirection at any point in the application, however, the longer it takes for the code to reach the point where a token is requested (explicitly through getToken, or implicitly through one of the SDK client methods), the higher the risk to have something else change the hash of the page, thus losing the ability to authenticate, and forcing the credential to trigger the redirection the next time getToken is called.

It's also important to note that, once a user is authenticated, a single credential can't authenticate another user, or logout.

Logout is particularly important because the endpoint used to authenticate single-page applications can cache the credentials that succeeded the last time, making it impossible to willingly change the authenticated user unless the browser local cached memory on the Azure endpoint side is cleared.

Challenges of the current approach

1. Although the loginStyle parameter allows users to change how the authentication happens, it is currently implied that changing this property will have no effect on how the architecture of the application needs to be, however not setting this parameter disables authentication in most browsers (popup) and setting the parameter to “redirect” is disruptive for browser applications.
2. The default popup behavior is disabled in most browsers, and the redirect behavior is disruptive for the browser application.
3. After the redirection happens, the credential retrieves the authentication code from the URL, which might not be obvious for users and could cause unintended behaviors.
4. No acknowledgement of the possibility of multiple users being authenticated in the browser.
5. There's no current way to pass metadata to the authentication endpoint, to know how to route the redirection or how to resume from a previously running process in the browser application.
6. No way to log out.

Concept of a new approach

In a new plugin package named @azure/identity-spa (after the spa redirect endpoint on the AAD app registration), two credentials could be provided RedirectCredential and PopupCredential.

These credentials would:

• Throw on Node.js (not isomorphic).
• Accept a state parameter through the options bag:
• Not automatically authenticate on getToken. They would throw AuthenticationRequiredError to indicate that the interactive authentication needs to be triggered by using the authenticate() method.

Additionally, the RedirectCredential would have a method called onPageLoad() to clearly indicate when to process the parameters received after the redirection ended, and that would also retrieve the state parameter initially.

const state = JSON.stringify({
  origin: window.location.href,
  user: user.id
})
const credential = new RedirectCredential(clientId, { state });
const client = new Client("url", credential);

window.onload = async () => {
  const { state } = await credential.onPageLoad();
  console.log({ state });
}

async function authenticate(): boolean {
  // To manually authenticate only if getToken throws an AuthenticationRequiredError
  try {
    await credential.getToken(scope);
    return true;
  } catch(e) {
    if (e.name === "AuthenticationRequiredError") {
      await credential.authenticate(scope, { state });
      // Redirect happens.
    }
    return false;
  }
}

async function getAzureValues() {
  await client.method(); // Will throw if the token is expired, or if the user hasn't authenticated.
}

[sadasant]

Question from Karishma: Can we open a new tab instead of redirection?

How that can work:

• If on getToken we open a new tab instead of redirecting it would do half of the trick, because we would be in a new tab, right
• To finish the experience, on page load of that new tab, once the user finishes authentication, it should close the tab.
• After closing the tab, we should be back in the first window, where maybe a promise is waiting for localStorage to contain the account information of the authenticated user.

Contingency:

• If the user closes the tab, we could have a timeout after which we would throw “AuthenticationRequiredError”.

So, it is possible! However, two questions:

1. Can MSAL do this?
2. How hard would it be to do this without MSAL? (maybe partially with MSAL, at least to retrieve the account from the cache).

Note: Maybe this comment specifically should be in a separate issue?

[github-actions]

Hi @sadasant, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.