- What browsers are supported?
- What versions of Angular are supported?
- Does
@azure/msal-angularsupport Server Side Rendering? - Does
@azure/msal-angularsupport standalone components? - Can
@azure/msal-angularbe used with Internet Explorer? - Can
@azure/msal-angularbe used with Microsoft Graph JavaScript SDK?
- What is the difference between
@azure/msal-angularv3 and v2? - What is the difference between
@azure/msal-angularv2 and v1? - How do I add tokens to API calls?
- How do I use my app with path/hash location strategy?
- How do I make sure all events are available when using path location strategy?
- How do I log users in when they hit the application?
- Why is my app looping when logging in with redirect?
- How do I implement self-service sign-up?
What if my question has not been answered?
Please see here for supported browsers.
MSAL Angular v4 currently supports Angular 15, 16, 17, 18, and 19.
MSAL Angular v3 supports Angular 15, 16, 17 and 18.
MSAL Angular v2 supports Angular 9, 10, 11, 12, 13 and 14.
Yes, server side rendering is supported through Angular universal. See our doc here for more information.
Note: MSAL Angular currently does not officially support server-side and prerendering capabilities. Using SSR with MSAL Angular may break your app.
MSAL Angular supports standalone components. Please see our redirect documentation for more information on using standalone components with redirects and our standalone sample for usage details.
MSAL Angular v3 no longer supports Internet Explorer.
MSAL Angular v2 and earlier supports IE 11. More information on configuration can be found here.
Yes, @azure/msal-angular can be used as a custom authentication provider for the Microsoft Graph JavaScript SDK. For an implementation, please refer to the sample: Angular SPA calling Graph API.
Please see our v2 to v3 upgrade guide for information on the differences between @azure/msal-angular v3 and v2, as well as changes to watch out for when upgrading.
Please see our v1 to v2 upgrade guide for information on the differences between @azure/msal-angular v1 and v2, as well as changes to watch out for when upgrading.
@azure/msal-angular provides the MsalInterceptor for obtaining tokens and adding them to HTTP requests. You may find the following links helpful:
- MsalInterceptor doc for details on configuration and use
- Initialization doc for basic set up
- Configuration doc for different ways to configure MSAL
- Samples for examples of usage
Please note that the MsalInterceptor is optional. You may wish to explicitly acquire tokens using the acquireToken APIs instead. The MsalInterceptor is provided for your convenience and may not fit all use cases. We encourage you to write your own interceptor if you have specific needs that are not addressed by the MsalInterceptor.
@azure/msal-angular supports both the PathLocationStrategy and HashLocationStrategy, which can be configured in the app-routing.module.ts of your app. See our samples list for the routing strategy demonstrated by each sample. See the Angular docs for more details on routing strategies.
See below for additional considerations for each strategy if you are wanting to log users in on page load.
There are certain situations where events emitted before a redirect are not able to be subscribed to after the redirect to a new page when using the path location strategy. An example is where an error thrown is caught by the MsalGuard, but the error event is not available to be subscribed to once the MsalGuard redirects to a login-failed route.
The MsalBroadcastService has optional configurations which allow the replay of past events. This can be set to replay a number of past events, such as the events before a redirect, when subscribed to on a new page load. See our Events documentation for configuration details.
To log your users in when they hit the application, without using a login button, do not call login in the ngOnInit in app.component.ts, as this can cause looping with redirects. Instead, we recommend setting the MsalGuard on your initial page, which will prompt users to log in before they reach other pages in your application. Our additional recommendations depend on your routing strategy below. Please all see our MsalGuard doc for more information.
For those using the PathLocationStrategy, we recommend:
- Setting the
MsalGuardon your initial page - Set your
redirectUrito'http://localhost:4200/auth' - Adding an
'auth'path to your routes, setting theMsalRedirectComponentas the component (this route should not be protected by theMsalGuard) - Making sure the
MsalRedirectComponentis bootstrapped - Optionally: adding
MsalGuardto all your routes if you want all your routes protected
Our Angular Modules Sample demonstrates use of the PathLocationStrategy.
For those using the HashLocationStrategy, we recommend:
- Setting the
MsalGuardon your initial page - Not setting the
MsalGuardon placeholder routes (e.g./code,/error) - Making sure the
MsalRedirectComponentis bootstrapped - Optionally: adding
MsalGuardto all your routes if you want all your routes protected
Our older Angular 11 sample demonstrates how to protect routes with MsalGuard and the hash location strategy.
One of the common reasons your app may be looping while logging in with redirects is due to improper usage of the loginRedirect() API. We recommend that you do not call loginRedirect() in the ngOnInit in the app.component.ts, as this will attempt to log in with every page load, often before any redirect has finished processing.
Redirects must be handled either with the MsalRedirectComponent or with calling handleRedirectObservable(). See our docs on redirects here for more information. Additionally, any interaction or account validation should be done after subscribing to the inProgress$ observable of MsalBroadcastService and filtering for InteractionStatus.None. Please see our sample for an example.
MSAL Angular supports self-service sign-up in the auth code flow. Please see our docs here for supported prompt values in the request and their expected outcomes, and here for an overview of self-service sign-up and configuration changes that need to be made to your Azure tenant. Please note that that self-service sign-up is not available in B2C and test environments.
Please see our MsalGuard doc for more information about securing routes with the MsalGuard.
The @azure/msal-browser instance used by @azure/msal-angular exposes multiple methods for getting account information. We recommend using getAllAccounts() to get all accounts, and getAccountByHomeId() and getAccountByLocalId() to get specific accounts. Note that while getAccountByUsername() is available, it should be a secondary choice, as it may be less reliable and is for convenience only. See the @azure/msal-browser docs for more details on account methods.
We recommend subscribing to the inProgress$ observable of MsalBroadcastService and filtering for InteractionStatus.None before retrieving account information. This ensures that all interactions have completed before getting account information. See our sample for an example of this use.
The msal-browser instance exposes getActiveAccount() and setActiveAccount() for active accounts.
We recommend subscribing to the inProgress$ observable of MsalBroadcastService and filtering for InteractionStatus.None before retrieving account information with getActiveAccount(). This ensures that all interactions have completed before getting account information.
We recommend setting the active account:
- After any action that may change the account, especially if your app uses multiple accounts. See here for an example of setting the account after a successful login.
- On initial page load. Wait until all interactions are complete (by subscribing to the
inProgress$observable ofMsalBroadcastServiceand filtering forInteractionStatus.None), check if there is an active account, and if there is none, set the active account. This could be the first account retrieved bygetAllAccounts(), or other account selection logic required by your app. See here for an example of checking and setting the active account on page load.
Note: Prior to @azure/[email protected] active account did not persist across page loads. If you are using @azure/[email protected] or earlier we recommend that you set the active account for each page load. In version 2.16.0 and above the active account will be cached in the cache location specified in your MSAL config and retrieved each time getActiveAccount is called.
Our Angular Modules Sample demonstrates basic usage. Your app may require more complicated logic to choose accounts.
If you have questions about specific errors you are receiving please see the following documents detailing some of the common errors:
First check the @azure/msal-browser FAQ to see if your question is answered there. Since @azure/msal-angular is a wrapper around @azure/msal-browser many questions you may have are answered there.
If you have questions about our roadmap you can find a high level overview of planned features and releases here.
If your question is not answered in this document or in the @azure/msal-browser FAQ you can open an issue and we will answer it as soon as we can.