diff --git a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx index aa174681a5d..b3ce4b9b983 100644 --- a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx +++ b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx @@ -13,10 +13,7 @@ redirect_from: An access token is an alternative to using your username and password for authenticating to npm when using the API or the npm command-line interface (CLI). An access token is a hexadecimal string that you can use to authenticate, and which gives you the right to install and/or publish your modules. -There are two types of access tokens available: - -- [Legacy tokens](#about-legacy-tokens) -- [Granular access tokens](#about-granular-access-tokens) +As of November 2025, access tokens can only be [Granular access tokens](#about-granular-access-tokens). Legacy access tokens are removed. You can create access tokens to give other tools (such as continuous integration testing environments) access to your npm packages. For example, GitHub Actions provides the ability to store [secrets](https://docs.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets), such as access tokens, that you can then use to authenticate. When your workflow runs, it will be able to complete npm tasks as you, including installing private packages you can access. @@ -25,13 +22,19 @@ You can work with tokens from the web or the CLI, whichever is easiest. What you npm token commands let you: - View tokens for easier tracking and management -- Create new legacy tokens +- Create new legacy tokens (deprecated) - Limit access according to IP address ranges (CIDR) - Delete/revoke tokens For more information on creating and viewing access tokens on the web and CLI, see "[Creating and viewing access tokens][create-token]". -## About legacy tokens +## About legacy tokens (Deprecated) + + + +**Warning:** Legacy access tokens are removed as of November 2025. + + Legacy tokens are created with the same permissions as the user who created them. The npm CLI automatically generates and uses a publish token when you run `npm login`. diff --git a/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx b/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx index 4e1501ed455..33bdb6061ba 100644 --- a/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx +++ b/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx @@ -8,37 +8,6 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc ## Creating access tokens -### Creating legacy tokens on the website - - - -**Note:** For greater security, we recommend using [granular access tokens](#creating-granular-access-tokens-on-the-website) instead of legacy read-only tokens or legacy automation tokens. For CI/CD workflows, consider using [trusted publishing](/trusted-publishers), which eliminates the need for long-lived tokens entirely. - - - -1. In the upper right corner of the page, click your profile picture, then click **Access Tokens**. - - - -2. Click **Generate New Token**, then select **legacy token** from the dropdown menu. - - - -3. (Optional) Name your token. - -4. Select the type of access token: - - **Read-only**: A read-only token can only be used to download packages from the registry. It will have permission to read any private package that you have access to. This is recommended for automation and workflows where you are installing packages, but not publishing new ones. - - - **Automation**: An automation token can download packages and publish new ones, but if you have two-factor authentication (2FA) configured on your account, it will **not** be enforced. You can use an automation token in continuous integration workflows and other automation systems to publish a package even when you cannot enter a one-time passcode. For enhanced security in CI/CD workflows, consider using [trusted publishing](/trusted-publishers) instead, which eliminates the need for long-lived tokens. - - - **Publish**: A publish token can perform any action on your behalf, including downloading packages, publishing packages, and changing user settings or package settings. If you have two-factor authentication configured on your account, you will be required to enter a one-time passcode when using a publish token. This is recommended for interactive workflows such as a CLI. - - - -5. Click **Generate Token**. - -6. Copy the token from the top of page. - ### Creating granular access tokens on the website 1. In the upper right corner of the page, click your profile picture, then click **Access Tokens**. @@ -83,38 +52,12 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc ### Creating tokens with the CLI -You can create tokens with **read-only** permissions or **read and publish** permissions with the CLI. - -**Note:** You cannot create legacy automation tokens or granular access tokens from the CLI. You must use the website to generate these types of tokens. For more information, see "[Creating legacy tokens on the website](#creating-legacy-tokens-on-the-website)" and "[Creating granular access tokens on the website](#creating-granular-access-tokens-on-the-website)." +**Note:** You cannot create granular access tokens from the CLI. You must use the website to generate these types of tokens. For more information, see "[Creating granular access tokens on the website](#creating-granular-access-tokens-on-the-website)." -- **Read-only:** Tokens that allow installation and distribution only, but no publishing or other rights associated with your account. -- **Publish:** The default setting for new tokens, and most permissive token type. Publish tokens allow installation, distribution, modification, publishing, and all rights that you have on your account. - -In addition, you can specify that the token is only valid for a specific IPv4 address range, using [CIDR][cidr-wiki] notation. The token will only be valid when used from the specified IP addresses. - -1. To create a new token, on the command line, run: - - `npm token create` for a read and publish token - - `npm token create --read-only` for a read-only token - - `npm token create --cidr=[list]` for a CIDR-restricted read and publish token. For example, `npm token create --cidr=192.0.2.0/24` - - `npm token create --read-only --cidr=[list]` for a CIDR-restricted read-only token -2. When prompted, enter your password. -3. If you have enabled [two-factor authentication][tfa], when prompted, enter a one-time password. -4. Copy the token from the **token** field in the command output. - -#### CIDR-restricted token errors - -If the CIDR string you enter is invalid or in an inappropriate format, you will get an error similar to the one below: - -``` -npm ERR! CIDR whitelist contains invalid CIDR entry: X.X.X.X./YY,Z.Z.. . . -``` - -Make sure you are using a valid IPv4 range and try creating the token again. - ## Viewing access tokens @@ -141,8 +84,7 @@ npm token list - **id:** Use the token ID to refer to the token in commands. - **token:** The first digits of the actual token. -- **create:** Date the token was created. -- **readonly:** If yes, indicates a read-only token. If no, indicates a token with both read and publish permissions. +- **created:** Date the token was created. - **CIDR whitelist:** Restricts token use by IP address. [tfa]: about-two-factor-authentication diff --git a/content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx b/content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx index 0d6eb12ca03..1b5642610a3 100644 --- a/content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx +++ b/content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx @@ -27,6 +27,12 @@ When generating an access token for use in a continuous integration environment, If you use a legacy token instead, by default, `npm token create` will generate a token with both read and write permissions. We recommend creating a read-only token: + + +**Warning:** Legacy access tokens are removed as of November 2025. + + + ``` npm token create --read-only ```