Azure-sdk-for-js: Confused about @azure/ms-node-auth vs @azure/identity vs MSAL.js

[southpolesteve]

• Package Name: @azure/identity
• Package Version: All
• Is the bug related to documentation in
  
  
  
  • [x] README.md
  
  
  • [x] source code documentation
  
  
  • [x] SDK API docs on https://docs.microsoft.com
  
  

Describe the bug
It is unclear what the difference is between @azure/ms-node-auth, @azure/identity, and MSAL.js. I do not know which lib to use when. If there is a doc that explains it, I cannot find one.

Expected behavior
A doc explaining each library and when they should be used with examples.

[ramya-rao-a]

Thanks for reporting @southpolesteve

@jonathandturner, @daviwil, @sadasant,
I was thinking that at the very least, we should do a couple of things here

• Update the readme for @azure/identity with notes on
  
  
  
  • how it integrates with MSAL
  
  
  • the fact that it uses v2 of AAD apis
  
  
  • that not all credential classes can be used in the browser
  
  
  • any scenario where one should use MSAL.js directly instead of @azure/identity
  
  
• Resolve #11359
• See what improvements we can do to Authenticate with the Azure management modules for JavaScript

[diberry]

@southpolesteve Can you list the top app types or identity issues, from your perspective, a customer is trying to figure out when asking this question?

Here are my questions I'm working to answer in docs - feel free to add your own?

• Q: App Developer - What do I need for social logins for Azure app hosted?
• Q: App Developer - What do I need for social logins for Azure app hosted with separate app user db to capture app-specific user info?
• Q: Social login User - After I have authorized an app to use my Microsoft identity, how do I revoke it?
• Q: App Developer - To have a Microsoft social login button for my own web app ("app registration") - is it an identity provider or is it AAD?
• Q: App Developer - How do I manage my Azure service resource authentication programmatically?

[southpolesteve]

@diberry I think you covered it well.

Maybe your first case captures this, but I think it can be broken in two:

• I am writing an app that needs many social logins (FB, GitHub, etc) only for identity purposes
• I am writing an app that specifically needs AAD login to access Azure. Like an internal app that lets my employees configure things that might be Azure resources under the hood.

I also think there is a "Just make it work any way you can" case for developers. I won't put an web app in production with vscode based login, but if it helps me get the app working or improves development, I want that to be possible.

[sadasant]

@southpolesteve Hello Steve! I'll be going through your feedback and making an update to our documentation as soon as possible. I'll get in contact with you in case I'm missing something. Thank you for submitting this issue!

[diberry]

@sadasant @ramya-rao-a Do you want to be included on Dev Center changes or localize this issue to your own SDK content?

[sadasant]

@diberry I'd like to be included in the Dev Center changes! If anything, for exposure.

[sadasant]

Hi again! Just to mention that I'll provide more information next week.

[sadasant]

@southpolesteve :

I believe that the questions @diberry is working on will be helpful for you! Let me answer some of the other things you mention here.

It is unclear what the difference is between @azure/ms-node-auth, @azure/identity, and MSAL.js

• @azure/ms-node-auth is the older authentication library! We're planning some better integration with it to facilitate users to move towards our newer library.
• @azure/identity is our newer library! This is the one that should be used if you want to authenticate any of our clients with the Azure services.
• MSAL.js is a library that connects to the system-specific keychains to provide a same authentication experience across environments. @azure/identity uses MSAL.js under the hood!

When should each library be used?

Even though all of them can be used, @azure/identity is the library that should be used with the Azure SDK for JS clients.

@ramya-rao-a :

Update the readme for @azure/identity

I've made an issue! https://github.com/Azure/azure-sdk-for-js/issues/12669 . I'll follow up this week.

See what improvements we can do to Authenticate with the Azure management modules for JavaScript.

I'll take a look and I'll make some notes!

---

While I move ahead with the readme update etc, how else can I be useful here? Please let me know if I'm missing something!

[sadasant]

On MSAL:

MSAL does offer several features that are not yet available in our SDK, but we will be adding support as soon as possible. These include more control on the caching and the storing of the credentials. However, we're working as closely as possible with the MSAL team, so we should be able to level up with them in a couple of months, as far as I'm understanding.

It's in our interest to request people to use the @azure/identity library as much as possible, instead of the possible alternatives, since direct customer feedback will help us make this experience better for everyone.

[seanknox]

@sadasant thanks for the explainer, I've been wondering the differences for awhile! What is the recommendation for providing browser-based authentication (e.g. for webapps needing a credential)? @azure/identity has a browser method that works well, but the package is only supported by a small number of Azure service libraries. I'm using @azure/arm-resources and @azure/arm-compute which require the older msRest.ServiceClientCredentials type of credential object.

[ramya-rao-a]

@seanknox You can use the @azure/ms-rest-browserauth package when working with @azure/arm-resources and @azure/arm-compute packages for authentication needs in the browser. The readmes on these packages should have a code snippet that shows this:

• Code snippet in readme for @azure/arm-compute
• Code snippet in readme for @azure/arm-resources

[seanknox]

@ramya-rao-a @azure/ms-rest-browserauth requires creating an AD app to authenticate users. Is that the only option for browser authentication, or is there another way can users authenticate directly to Microsoft auth, like @azure/identity's InteractiveBrowserCredential method?

[sadasant]

@seanknox Hello hello! I wonder if a credential like @azure/identity's DeviceCodeCredential can work for you. Would that be useful? In ms-rest-nodeauth we have interactiveLoginWithAuthResponse, which is similar.

[sadasant]

I understand that this wouldn't be on the browser though. Would it be possible to move to @azure/identity 's InteractiveBrowserCredential instead?

[ramya-rao-a]

@azure/ms-rest-browserauth requires creating an AD app to authenticate users. Is that the only option for browser authentication, or is there another way can users authenticate directly to Microsoft auth, like @azure/identity's InteractiveBrowserCredential method?

@seanknox All credential classes in @azure/identity make use of the client id and therefore require you to create an app registration. The ones that don't default to the one corresponding to Azure CLI. So yes, the recommended way is to create an app registration and pass the clientId when creating the credential.

@sadasant The packages @azure/arm-resources and @azure/arm-compute do not support @azure/identity. So, @seanknox won't be able to use it.

[sadasant]

Why don't they support @azure/identity? I'm interested in making it work.

If it makes sense, is it because of Continuous Access Evaluation (CAE) challenge based authentication? I believe this is important for ARM resources. We're adding support for CAE this month.

[ramya-rao-a]

This has nothing to do with CAE

All the management plane packages (the ones dealing with resource management) at the moment are auto generated. The generated code works with the credentials from @azure/ms-rest-nodeauth and @azure/ms-rest-browserauth. They are of a different shape than the TokenCredential interface which is implemented by all the credentials in the @azure/identity package. We do have a feature request to update the code generator to generate code that will work with the credentials from @azure/identity as well. But it will take a while to update the code generator and re-generate over 100 management plane packages.

[ramya-rao-a]

@seanknox Please log an issue in the repo for @azure/ms-rest-browserauth for more on that package

We have https://github.com/Azure/azure-sdk-for-js/issues/12669 tracking improvements to the @azure/identity package which we will tackle this month.

We are independently tracking other efforts to improve documentation around auth. So, closing this issue.

Thanks for your patience everyone

[leolumicrosoft]

then how about library @azure/msal-browser, this lib is using PublicClientApplication to achieve browser login to use graph or other web API. what distinguish it from @azure/identity?

[ramya-rao-a]

@leolumicrosoft,

@azure/identity contains multiple credential classes, all following the TokenCredential interface. You would need to use these credentials when using our newer set of libraries.

When in browser, the only credential that applies from @azure/identity is the InteractiveBrowserCredential which at the moment uses the msal package. We are in the process of moving to use @azure/msal-browser instead. See #13155 and #13263

You are free to use @azure/msal-browser directly as long as you create your own credential class that follows the interface expected by the client constructor in the Azure package that you are using

• The client constructors in the new JS packages require a credential that follows the TokenCredential interface
• The client constructors in the rest of the JS packages in this repo require a credential that follows the ServiceClientCredential interface. An example can be found at Authenticating with an existing token

[leolumicrosoft]

Thank you, @ramya-rao-a. Thank you for the detail reply, I started to understand more of AD related javascript SDK.
I highlight a few points I learned through experiment as it might be helpful to people who just started exploring AD authenticate topic. Please correct anything that is inaccurate.

1. DefaultAzureCredential in @azure/identity is to be used in backend service application code, or it is used in a locally running application to get credential. But this library is not used in frontend code such as JavaScript in html.

2. Browser javascript code can utilize @azure/msal-browser or earlier @azure/ms-rest-browserauth. @azure/msal-browser uses auth code flow which allows stricter control of protected resource access, while @azure/ms-rest-browserauth uses implicit flow

3. Azure services exposes RESTful endpoints which need token. There are two types of token, one is for the resource management (or control plane REST api). This token can be get through credential.getToken("https://management.azure.com/.default"). such as listing all data storage account in your azure account.

4. The other type of RESTful endpoint is data plane REST api such as listing keyvault keys or querying blob storage content . To fetch this type of token, you need to get from each specified URI of the service, for example
   azure keyvault: credential.getToken("https://vault.azure.net/.default")
   azure digitaltwin: credential.getToken("https://digitaltwins.azure.net/.default")

Both 3 and 4 can be tested using postman after you get the token by using DefaultAzureCredential in a simple locally run script with "az login".

These points maybe very basic but it still give me three days to have a clearer insight into them.