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 71035e38413..4e1501ed455 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 @@ -12,7 +12,7 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc -**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](/packages-and-modules/securing-your-code/trusted-publishers), which eliminates the need for long-lived tokens entirely. +**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. @@ -29,7 +29,7 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc 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](/packages-and-modules/securing-your-code/trusted-publishers) instead, which eliminates the need for long-lived tokens. + - **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. 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 c9e8f078918..0d6eb12ca03 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 @@ -8,7 +8,7 @@ You can use access tokens to test private npm packages with continuous integrati ## Recommended: Use trusted publishing for package publishing -For publishing packages from CI/CD workflows, we recommend using [trusted publishing](/packages-and-modules/securing-your-code/trusted-publishers) instead of access tokens. Trusted publishing uses OpenID Connect (OIDC) to provide secure publishing that eliminates the security risks associated with long-lived tokens. +For publishing packages from CI/CD workflows, we recommend using [trusted publishing](/trusted-publishers) instead of access tokens. Trusted publishing uses OpenID Connect (OIDC) to provide secure publishing that eliminates the security risks associated with long-lived tokens. Trusted publishing is supported for: @@ -35,7 +35,7 @@ For more information on creating access tokens, including CIDR-whitelisted token ### Continuous deployment -For publishing packages in continuous deployment environments, we strongly recommend using [trusted publishing](/packages-and-modules/securing-your-code/trusted-publishers) when available, as it provides enhanced security without requiring token management. +For publishing packages in continuous deployment environments, we strongly recommend using [trusted publishing](/trusted-publishers) when available, as it provides enhanced security without requiring token management. If trusted publishing is not available for your CI/CD provider, you may create an [automation token][create-token] on the website. This will allow you to publish even if you have two-factor authentication enabled on your account. diff --git a/content/packages-and-modules/contributing-packages-to-the-registry/creating-and-publishing-unscoped-public-packages.mdx b/content/packages-and-modules/contributing-packages-to-the-registry/creating-and-publishing-unscoped-public-packages.mdx index e6c703c590d..80fd70a7478 100644 --- a/content/packages-and-modules/contributing-packages-to-the-registry/creating-and-publishing-unscoped-public-packages.mdx +++ b/content/packages-and-modules/contributing-packages-to-the-registry/creating-and-publishing-unscoped-public-packages.mdx @@ -72,7 +72,7 @@ npm install path/to/my-package - **Note:** If you use GitHub Actions or GitLab CI/CD to publish your packages, consider using [trusted publishing](/packages-and-modules/securing-your-code/trusted-publishers) for enhanced security. Trusted publishing automatically generates provenance information and eliminates the need for access tokens in your CI/CD workflows. For more information, see "[Generating provenance statements][provenance-how-to]." + **Note:** If you use GitHub Actions or GitLab CI/CD to publish your packages, consider using [trusted publishing](/trusted-publishers) for enhanced security. Trusted publishing automatically generates provenance information and eliminates the need for access tokens in your CI/CD workflows. For more information, see "[Generating provenance statements][provenance-how-to]." diff --git a/content/packages-and-modules/securing-your-code/generating-provenance-statements.mdx b/content/packages-and-modules/securing-your-code/generating-provenance-statements.mdx index 1a7c73037d9..a4dbc2f2041 100644 --- a/content/packages-and-modules/securing-your-code/generating-provenance-statements.mdx +++ b/content/packages-and-modules/securing-your-code/generating-provenance-statements.mdx @@ -42,7 +42,7 @@ Before you can publish your packages with provenance, you must: - GitHub Actions. For more information, see "[Publishing packages with provenance via GitHub Actions][github-provenance]." - GitLab CI/CD. For more information, see "[Publishing packages with provenance via GitLab CI/CD][gitlab-provenance]." -**Note:** If you use [trusted publishing](/packages-and-modules/securing-your-code/trusted-publishers), provenance attestations are automatically generated for your packages without requiring the `--provenance` flag. This provides enhanced security and eliminates the need for access tokens in your CI/CD workflows. +**Note:** If you use [trusted publishing](/trusted-publishers), provenance attestations are automatically generated for your packages without requiring the `--provenance` flag. This provides enhanced security and eliminates the need for access tokens in your CI/CD workflows. ## Publishing packages with provenance via GitHub Actions diff --git a/content/packages-and-modules/securing-your-code/requiring-2fa-for-package-publishing-and-settings-modification.mdx b/content/packages-and-modules/securing-your-code/requiring-2fa-for-package-publishing-and-settings-modification.mdx index 8896d793b73..7e3b3d0bccc 100644 --- a/content/packages-and-modules/securing-your-code/requiring-2fa-for-package-publishing-and-settings-modification.mdx +++ b/content/packages-and-modules/securing-your-code/requiring-2fa-for-package-publishing-and-settings-modification.mdx @@ -8,7 +8,7 @@ To protect your packages, as a package publisher, you can require everyone who h You may also choose to allow publishing with either two-factor authentication _or_ with [automation tokens][creating-automation-token]. This lets you configure automation tokens in a CI/CD workflow, but requires two-factor authentication from interactive publishes. -For CI/CD workflows, consider using [trusted publishing](/packages-and-modules/securing-your-code/trusted-publishers), which provides secure, token-free publishing that automatically enforces strong authentication without requiring manual token management. +For CI/CD workflows, consider using [trusted publishing](/trusted-publishers), which provides secure, token-free publishing that automatically enforces strong authentication without requiring manual token management. ## Configuring two-factor authentication diff --git a/content/packages-and-modules/securing-your-code/trusted-publishers.mdx b/content/packages-and-modules/securing-your-code/trusted-publishers.mdx index 61a93324081..ae5b873ebd5 100644 --- a/content/packages-and-modules/securing-your-code/trusted-publishers.mdx +++ b/content/packages-and-modules/securing-your-code/trusted-publishers.mdx @@ -228,7 +228,7 @@ While trusted publishing handles the publish operation, you may still need authe - run: npm publish ``` -Always use [read-only granular access tokens](/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens#creating-granular-access-tokens-on-the-website) for installing dependencies. This limits potential damage if the token is ever compromised. +Always use [read-only granular access tokens](/creating-and-viewing-access-tokens#creating-granular-access-tokens-on-the-website) for installing dependencies. This limits potential damage if the token is ever compromised. ### Additional security measures