Skip to content

Latest commit

 

History

History
124 lines (71 loc) · 10.1 KB

File metadata and controls

124 lines (71 loc) · 10.1 KB

FAQs

General

When is MSAL Node used?

MSAL Node supports server based authentication for public/confidential apps. This is more applicable for server based authentication scenarios/Web APIs that need authentication. A full list of supported scenarios can be found here and supported flows are listed here

What is the status of ADAL Node? Is a migration guide available?

ADAL Node is currently in maintanence and we advise all users to move to MSAL Node as possible. MSAL Node is designed to completely replace ADAL node. For those looking to migrate from ADAL to MSAL we have provided a Migration Document to help in the migration. Please note that all apps may not have a smooth migration as this is complete overhaul of the old functionality.

What are the services supported?

MSAL Node supports AAD, MSA, ADFS and B2C. Our samples demonstrate the usage here. MSAL Node also supports single and multi tenanted apps.

Note: ADFS is currently supported, a standalone sample is not yet published. Please checkout this space for an update soon.

What is a Public App or a Confidential App? What do I need to know during app registration?

Please find this in the MSAL basics

What does authority string default to if I provide "authority" and "azureCloudOptions"?

If the developer provides azureCloudOptions, MSAL.js will overwrite any value provided in the authority. MSAL.js will also give preference to the parameters provided in a request over configuration. Please note that if azureCloudOptions are set in the configuration, they will take precedence over authority in the request. If the developer needs to overwrite this, they need to set azureCloudOptions in the request.

What will be the token lifetimes?

  • AAD: Please find the latest reference for AAD here. Please note that few of the configurable features for specific token types are retired recently.
  • B2C: Please find the B2C token lifetime guidance here

How do I get the Refresh Token?

MSAL Node does not expose refresh tokens for security reasons. Instead, we manage the refresh token through the cache and update it as required to fetch the corresponding Id Token and Access Token for the developer. Use the appropriate acquireToken* API to obtain access tokens, and MSAL will ensure they are renewed if necessary. If you have a refresh token acquired by other means, you can use the acquireTokenByRefreshToken API (see also: Refresh Token sample). More details on AAD tokens can be found here

Is Electron supported?

Yes. Please refer to MSAL Node samples.

Is interactive flow supported?

Currently No. Authentication for MSAL Node using authorization code grant is a two legged flow, as detailed here. There are plans to provide a single API to achieve this, and invoke the browser on the user's behalf. However it is currently not supported.

Are SPAs supported by MSAL Node?

Please refer to MSAL Browser for SPA based use cases. MSAL Node should be a choice for desktop apps, web apps, web APIs or server side authentication scenarios.

What is MSAL Node extensions? What is a Cache Plugin?

MSAL Node extensions is a support library for MSAL Node which offers secure mechanisms for client applications to perform cross-platform token cache serialization and persistence. Please find the usage, samples and more about this here

Can the cache plugin provided in MSAL Node extensions be used in Electron applications?

Yes, it can. In case you run into node version related issues, refer to this note that provides the steps to troubleshoot.

What versions of Node.js are supported? How do I bypass the installation error if I want to use an active development Node.js version?

MSAL Node officially supports even numbered stable LTS releases as documented here.

If you want to work around this, please note:

  • Yarn: Pass the --ignore-engines flag to the yarn command.
  • npm: Add engine-strict=false to your .npmrc file.

How do I implement self-service sign-up with MSAL Node?

MSAL Node 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.

Why doesn't my app function correctly when it's running behind a proxy?

Developers can provide a proxyUrl string in the system config options as detailed here. Developers can also implement their own NetworkManager by instantiating an INetworkModule and building proxy support in it.

How do I implement a custom http(s) agent in MSAL Node?

Developers can use a custom http(s) agent by providing a customAgentOptions object in the system config options as detailed here. Developers can also implement their own NetworkManager by instantiating an INetworkModule and building custom http(s) agent support in it.

B2C

How do I handle the password-reset user-flow?

The new password reset experience is now part of the sign-up or sign-in policy. When the user selects the Forgot your password? link, they are immediately sent to the Forgot Password experience.

Our recommendation is to move to the new password reset experience since it simplifies the app state and reduces error handling on the user-end. If for some reason you have to use the legacy password-reset user-flow, you'll have to handle the AADB2C90118 error code returned from B2C service when a user selects the Forgot your password? link. To see how this is done, refer to the sample: MSAL Node B2C web app sample (using auth code)

Compatibility

Can I use MSAL Node with Microsoft Graph JavaScript SDK?

Yes, MSAL Node can be used as a custom authentication provider for the Microsoft Graph JavaScript SDK. For an implementation, please refer to the sample: Express Web App calling Graph API.

Can I provision MSAL Node apps via command-line?

Yes, we recommend the new Powershell Graph SDK for doing so. For instance, the script below creates an Azure AD application with a custom redirect URI of type Mobile and Desktop apps (aka InstalledClient) and User.Read permission for Microsoft Graph in a tenant specified by the user, and then provisions a service principal in the same tenant based on this application object:

Import-Module Microsoft.Graph.Applications

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Connect-MgGraph -TenantId "ENTER_TENANT_ID_HERE" -Scopes "Application.ReadWrite.All"

# User.Read delegated permission for Microsoft Graph
$mgUserReadScope = @{
    "Id" = "e1fe6dd8-ba31-4d61-89e7-88639da4683d" # permission Id
    "Type" = "Scope"
}

# Add additional permissions to array below
$mgResourceAccess = @($mgUserReadScope)

[object[]]$requiredResourceAccess = @{
    "ResourceAppId" = "00000003-0000-0000-c000-000000000000" # MS Graph App Id
    "ResourceAccess" = $mgResourceAccess
}

# Create the application
$msalApplication = New-MgApplication -displayName myMsalDesktopApp `
    -SignInAudience AzureADMyOrg `
    -PublicClient @{RedirectUris = "msal://redirect"} `
    -RequiredResourceAccess $requiredResourceAccess

# Provision the service principal
New-MgServicePrincipal -AppId $msalApplication.AppId