[Identity] Create a separate package for optional native components of @azure/identity

In Identity, we would like to avoid adding any packages with native binaries as dependencies (not even peer or optional dependencies).

• VisualStudioCodeCredential depends on keytar, which uses native binaries to commmunicate with the platform credential manager.
• persistence through msal-node-extensions requires a native DPAPI component that is installed with the package. As Mike reported here: https://github.com/Azure/azure-sdk-for-js/pull/14343#issuecomment-801458068 some customers refuse or are unable to install native dependencies.

We would like to provide these facilities through a separate package that can inject or provide these native module dependencies outside of the mainline identity package. This issue tracks that work.

[ramya-rao-a]

@octogonz, @iclanton,

While we wait for v2, if it is indeed the case that rush currently uses only the device code login flow and you do not care about whether the underlying implementation for this uses the newer MSAL or not, then another option for you can be to update the identity dependency to use ~1.0.0 instead of say ^1.0.0. The keytar dependency came into play when we added the VisualStudioCodeCredential in 1.1.0. So, versions 1.0.* should be safe for you to use device code login flow from @azure/identity.

Once we have resolved this issue for native components, you can get right back to using the latest identity package

[witemple-msft]

@octogonz My title change apparently wasn’t saved. It’s updated now. As far as timeline, we are pushing towards a GA solution within the next month and a half or so, beta availability for a stripped down package within a couple of weeks. @azure/identity 2.0.0 will not have any native package dependencies, peer, optional, or otherwise, and native extensions to identity will be moved into their own package.

@iclanton The principle of @azure/identity is to be a fixpoint within the Azure SDK for JavaScript for AAD authentication. In the backend, we are using MSAL. If you aren’t using Identity to work with the Azure SDK data-plane libraries, you could consider using @azure/msal-node and its support for device code grants directly, but it’s a more involved API than Identity is. We are reluctant to separate the components of identity at all, but the native dependencies present enough of a problem to justify removing the VS Code Credential.

Local dev builds of 2.0.0-beta.3 are about 25MB on disk, as we are able to throw off a bit by not installing keytar and prebuild-install. It’s up to you all if that’s acceptable. @mikeharder I hope to have a basic version of this merged tomorrow or Monday so we should have a dev artifact by Tuesday.

CC @schaabs, @bterlson