add references to oidc in other files

Author: leobalter

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>
 
-**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.
+**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>
 
@@ -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.
+   - **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.
 
    - **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.
 

content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx

@@ -6,6 +6,16 @@ redirect_from:
 
 You can use access tokens to test private npm packages with continuous integration (CI) systems, or deploy them using continuous deployment (CD) systems.
 
+## 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, token-free publishing that eliminates the security risks associated with long-lived tokens.
+
+Trusted publishing is supported for:
+- [GitHub Actions](https://github.com/features/actions) (GitHub-hosted runners)
+- [GitLab CI/CD](https://docs.gitlab.com/ci/pipelines/) (GitLab.com shared runners)
+
+If you use a different CI/CD provider, or if you need to install private packages (not publish), you can use access tokens as described below.
+
 ## Create a new access token
 
 Create a new access token that will be used only to access npm packages from a CI/CD server.
@@ -24,7 +34,9 @@ For more information on creating access tokens, including CIDR-whitelisted token
 
 ### Continuous deployment
 
-Since continuous deployment environments usually involve the creation of a deploy artifact, you may wish to 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.
+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.
+
+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.
 
 ### Interactive workflows
 

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>
 
-   **Note:** If you use GitHub Actions to publish your packages, you can generate provenance information for each package you publish. 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](/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>
 

content/packages-and-modules/securing-your-code/generating-provenance-statements.mdx

@@ -42,6 +42,8 @@ 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.
+
 ## Publishing packages with provenance via GitHub Actions
 
 In order to establish provenance, you must use a supported cloud CI/CD provider and a cloud-hosted runner to publish your packages. GitHub Actions is a supported CI/CD platform that allows you to automate software development tasks. For more information, see [GitHub Actions][github-actions] in the GitHub documentation.

content/packages-and-modules/securing-your-code/requiring-2fa-for-package-publishing-and-settings-modification.mdx

@@ -8,6 +8,8 @@ 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.
+
 ## Configuring two-factor authentication
 
 1. <>{shared['user-login'].text}</>