Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confused about @azure/ms-node-auth vs @azure/identity vs MSAL.js #12565

Closed
3 tasks done
southpolesteve opened this issue Nov 16, 2020 · 21 comments
Closed
3 tasks done

Confused about @azure/ms-node-auth vs @azure/identity vs MSAL.js #12565

southpolesteve opened this issue Nov 16, 2020 · 21 comments
Assignees
Labels
Azure.Identity Client This issue points to a problem in the data-plane of the library. Docs
Milestone

Comments

@southpolesteve
Copy link
Contributor

southpolesteve commented Nov 16, 2020

  • Package Name: @azure/identity
  • Package Version: All
  • Is the bug related to documentation in

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.

@ghost ghost added the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Nov 16, 2020
@ramya-rao-a
Copy link
Contributor

Thanks for reporting @southpolesteve

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

@ramya-rao-a ramya-rao-a added Azure.Identity Client This issue points to a problem in the data-plane of the library. Docs labels Nov 18, 2020
@ghost ghost removed the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Nov 18, 2020
@ramya-rao-a ramya-rao-a added this to the MQ-2020 milestone Nov 18, 2020
@diberry
Copy link
Contributor

diberry commented Nov 18, 2020

@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
Copy link
Contributor Author

@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
Copy link
Contributor

@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
Copy link
Contributor

diberry commented Nov 20, 2020

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

@sadasant
Copy link
Contributor

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

@sadasant
Copy link
Contributor

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

@sadasant
Copy link
Contributor

sadasant commented Nov 23, 2020

@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! #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
Copy link
Contributor

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.

@ramya-rao-a ramya-rao-a assigned ramya-rao-a and unassigned sadasant Dec 2, 2020
@seanknox
Copy link

seanknox commented Jan 6, 2021

@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
Copy link
Contributor

ramya-rao-a commented Jan 6, 2021

@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:

@seanknox
Copy link

seanknox commented Jan 7, 2021

@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
Copy link
Contributor

sadasant commented Jan 8, 2021

@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
Copy link
Contributor

sadasant commented Jan 8, 2021

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
Copy link
Contributor

ramya-rao-a commented Jan 12, 2021

@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
Copy link
Contributor

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
Copy link
Contributor

ramya-rao-a commented Jan 12, 2021

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
Copy link
Contributor

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

We have #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

openapi-sdkautomation bot pushed a commit to AzureSDKAutomation/azure-sdk-for-js that referenced this issue Jan 29, 2021
added api-version parameter in agreements APIs (Azure#12565)

* added api-version parameter in agreements apis

* updated api-version parameter

* updated confluent.json

* updated confluent.json
@leoluKL
Copy link

leoluKL commented Jan 29, 2021

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
Copy link
Contributor

@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

@leoluKL
Copy link

leoluKL commented Feb 1, 2021

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Azure.Identity Client This issue points to a problem in the data-plane of the library. Docs
Projects
None yet
Development

No branches or pull requests

6 participants