- What browsers are supported?
- What versions of Angular are supported?
- Does
@azure/msal-angularsupport Server Side Rendering? - 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-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 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 currently supports Angular 9, 10, 11, and 12.
Yes, server side rendering is supported through Angular universal. See our doc here for more information.
Yes, @azure/msal-angular does support IE 11. More information can 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 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.
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 10 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
See our Angular 11 sample for examples of how to protect routes with MsalGuard.
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 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 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 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 and 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/msal-browser@2.16.0 active account did not persist across page loads. If you are using @azure/msal-browser@2.15.0 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 11 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.