If you’ve used any applications that required connecting your personal Microsoft or Entra ID account, you’re probably familiar with the typical “authentication dance” – you see a browser window pop up, you enter your credentials, then you can close the browser, and the application is magically authenticated. The next application you launch does the same thing, and you need to go through the hassle of selecting your account, entering your credentials again, and then going back to your work.

This has been the standard for quite some time, but it also lagged behind the modern security landscape. In the past couple of years, threat actors became more advanced and have started leveraging significantly more complex techniques to exfiltrate and misuse user credentials. Access and refresh tokens, the two credential artifacts that applications store after you sign in, became a prime target for those that want to steal personal and organizational data.

To protect against both this and many other classes of emerging threats, we’ve been investing in making Entra ID-based authentication flows more robust, secure, and easier to use by driving adoption of authentication brokers.

An authentication broker is an application that runs on a user’s machine that manages the authentication handshakes and token maintenance for connected accounts, such as your personal Microsoft or work and school Entra ID accounts. Unlike browser-based authentication flows, an authentication broker provides a much smoother user experience. Instead of sending the user out to sign in outside the app, they simply get a prompt to either select an existing account that is already connected or add a new account.

Once an account is connected to an authentication broker, it can be securely used across many other installed applications that need to sign users in without going through the trouble of re-entering the same credentials over and over.

On Windows machines, the authentication broker is the Web Account Manager (WAM) – a feature of the operating system available in Windows 10 (Version 1703 – Creators Update) and above as well as Windows Server 2019 and above.

Authentication brokers bring with them many benefits that go beyond an improved user experience, that include:

• Enhanced security by default. As new security enhancements are developed, they will be seamlessly delivered with the broker, without developers needing to update their application logic. This significantly reduces the update and maintenance burden and ensures that customers get the best protection no matter what.
• Feature support. With the help of the broker, applications can natively access enhanced security capabilities such as Windows Hello, conditional access policies, and FIDO keys in a compliant and consistent manner. This means that organizational policies can be applied and respected by all client applications.
• System integration. Applications that use the broker plug-and-play with the built-in account picker, allowing the user to quickly pick an existing account instead of reentering the same credentials over and over. Once an account is connected, it can be easily used across other installed tools on the same computer.
• Token protection. WAM and other authentication brokers ensure that the refresh tokens are bound to the device, helping prevent attacks where a malicious actor exfiltrates user credentials and attempts to access data from another device. By default, authentication brokers ensure that the refresh tokens are protected and not accessible to the client application. And even in the worst case, a leaked refresh token is unusable outside the device it was issued on. Learn more in the Token Protection documentation.

Developer tool support for authentication brokers

Our developer tools are designed for a wide range of professionals, including software engineers, IT administrators, data scientists, DevOps teams, and more. These individuals and their organizations require strong security measures within their development environments and tools to effectively build, deploy, and maintain the suite of applications and services.

To ensure that their credentials are secure, we’ve started rolling out updates to Visual Studio, Visual Studio Code, Azure CLI, Azure PowerShell, and a range of our libraries, including Azure Identity and MSAL, to use authentication brokers such as WAM, as well as upcoming macOS and Linux brokers, out-of-the-box.

In most of our tools running on Windows, WAM is already the default way to sign in with Microsoft personal and Entra ID accounts. This includes:

• Visual Studio 2022, starting with version 17.11
• Visual Studio Code, starting with version 1.97
• Azure PowerShell, starting with version 12.0.0
• Azure CLI, starting with version 2.61.0

As new authentication brokers are developed, we expect this pattern to become the norm across macOS and Linux systems as well.

The change to use authentication brokers instead of browser-based authentication is entirely transparent to our customers and does not require any added work. When customers sign in, they will use the built-in OS account picker that will allow them to connect their accounts for single sign-on (SSO).

We are excited about taking another step in securing our customers and their credentials.

Feedback and support

If you or your organization are encountering any issues with WAM-based authentication, refer to Microsoft Entra authentication and authorization error codes and Errors associated with Web Account Manager (WAM) articles to troubleshoot your issue.

If you require additional support related to identity or account management, please report your issues in the Microsoft Support Community. If you are part of an organization that has a support contract with Microsoft, we recommend directly engaging with your designated support contact.