Skip to content

Migrate the msal-node-extensions to use @napi-rs/keyring instead of keytar #7170

Open
@kenotron

Description

@kenotron

Core Library

MSAL Node (@azure/msal-node)

Wrapper Library

MSAL Node Extensions (@azure/msal-node-extensions)

Public or Confidential Client?

Public

Description

Currently, the msal-node-extensions imposes a dependency on keytar. This is a cross-platform library that abstracts keystore. On Windows, this extension already handles credential persistence via the in-built Data Protection. On Linux, the keytar library depends on libsecret, which is then dependent on a dbus... this is not available in headless workloads like WSL2. A better approach is to utilize @napi-rs/keyring which is a thin napi-rs wrapper on top of the keyring-rs crate written in Rust. There, the secret store is implemented natively in Rust as well. https://www.npmjs.com/package/@napi-rs/keyring uses https://github.com/hwchen/keyring-rs uses https://github.com/hwchen/secret-service-rs ... this means that headless workloads can also use keystores with this implementation.

In addition, the author of the @napi-rs/keyring was recently awarded OSS fund from MSFT which means that the author is a credible source of quality code. I highly recommend us to move away from keytar.

Source

Internal (Microsoft)

Metadata

Metadata

Assignees

No one assigned

    Labels

    Needs: Attention 👋Awaiting response from the MSAL.js teamfeature-unconfirmedmsal-nodeRelated to msal-node packagemsal-node-extensionsRelated to msal-node-extensions packagepublic-clientIssues regarding PublicClientApplicationsquestionCustomer is asking for a clarification, use case or information.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions