Skip to main content

Automatic token authentication

GitHub provides a token that you can use to authenticate on behalf of GitHub Actions.

Nota:

Actualmente los ejecutores hospedados por GitHub no se admiten en GitHub Enterprise Server. Puede ver más información sobre la compatibilidad futura planeada en GitHub public roadmap.

About the GITHUB_TOKEN secret

At the start of each workflow job, GitHub automatically creates a unique GITHUB_TOKEN secret to use in your workflow. You can use the GITHUB_TOKEN to authenticate in the workflow job.

When you enable GitHub Actions, GitHub installs a GitHub App on your repository. The GITHUB_TOKEN secret is a GitHub App installation access token. You can use the installation access token to authenticate on behalf of the GitHub App installed on your repository. The token's permissions are limited to the repository that contains your workflow. For more information, see Permissions for the GITHUB_TOKEN.

Before each job begins, GitHub fetches an installation access token for the job. GITHUB_TOKEN expira cuando finaliza un trabajo o después de un máximo de 24 horas.

The token is also available in the github.token context. For more information, see Acceso a información contextual sobre ejecuciones de flujo de trabajo.

Using the GITHUB_TOKEN in a workflow

You can use the GITHUB_TOKEN by using the standard syntax for referencing secrets: ${{ secrets.GITHUB_TOKEN }}. Examples of using the GITHUB_TOKEN include passing the token as an input to an action, or using it to make an authenticated GitHub API request.

Importante

An action can access the GITHUB_TOKEN through the github.token context even if the workflow does not explicitly pass the GITHUB_TOKEN to the action. As a good security practice, you should always make sure that actions only have the minimum access they require by limiting the permissions granted to the GITHUB_TOKEN. For more information, see Permissions for the GITHUB_TOKEN.

Al usar GITHUB_TOKEN del repositorio para realizar tareas, los eventos desencadenados por GITHUB_TOKEN, a excepción de workflow_dispatch y repository_dispatch, no crearán una ejecución de flujo de trabajo. Esto impide que crees ejecuciones de flujo de trabajo recursivas por accidente. Por ejemplo, si una ejecución de flujo de trabajo inserta código mediante GITHUB_TOKEN del repositorio, un nuevo flujo de trabajo no se ejecutará incluso cuando el repositorio contenga un flujo de trabajo configurado para ejecutarse cuando se produzcan eventos push.

Las confirmaciones insertadas por un flujo de trabajo de GitHub Actions que usa GITHUB_TOKEN no desencadenan una compilación de GitHub Pages.

Example 1: passing the GITHUB_TOKEN as an input

En este flujo de trabajo de ejemplo se usa la CLI de GitHub, que necesita GITHUB_TOKEN como valor para el parámetro de entrada GH_TOKEN:

YAML
name: Open new issue
on: workflow_dispatch

jobs:
  open-issue:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
    steps:
      - run: |
          gh issue --repo ${{ github.repository }} \
            create --title "Issue title" --body "Issue body"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Example 2: calling the REST API

You can use the GITHUB_TOKEN to make authenticated API calls. This example workflow creates an issue using the GitHub REST API:

name: Create issue on commit

on: [ push ]

jobs:
  create_issue:
    runs-on: ubuntu-latest
    permissions:
      issues: write
    steps:
      - name: Create issue using REST API
        run: |
          curl --request POST \
          --url http(s)://HOSTNAME/api/v3/repos/${{ github.repository }}/issues \
          --header 'authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' \
          --header 'content-type: application/json' \
          --data '{
            "title": "Automated issue for commit: ${{ github.sha }}",
            "body": "This issue was automatically created by the GitHub Action workflow **${{ github.workflow }}**. \n\n The commit hash was: _${{ github.sha }}_."
            }' \
          --fail

Permissions for the GITHUB_TOKEN

For information about the API endpoints GitHub Apps can access with each permission, see Permisos que requieren las Github Apps.

The following table shows the permissions granted to the GITHUB_TOKEN by default. People with admin permissions to an organization or repository can set the default permissions to be either permissive or restricted. For information on how to set the default permissions for the GITHUB_TOKEN for your enterprise, organization, or repository, see Requerir políticas para las GitHub Actions en tu empresa, Inhabilitar o limitar GitHub Actions para tu organización, or Administrar los ajustes de las GitHub Actions de un repositorio.

ScopeDefault access
(permissive)
Default access
(restricted)
Maximum access for
pull requests from
public forked repositories
actionsread/writenoneread
checksread/writenoneread
contentsread/writereadread
deploymentsread/writenoneread
discussionsread/writenoneread
issuesread/writenoneread
metadatareadreadread
modelsreadnonenone
packagesread/writereadread
pagesread/writenoneread
pull-requestsread/writenoneread
repository-projectsread/writenoneread
security-eventsread/writenoneread
statusesread/writenoneread

Nota:

  • When a workflow is triggered by the pull_request_target event, the GITHUB_TOKEN is granted read/write repository permission, even when it is triggered from a public fork. For more information, see Events that trigger workflows.
  • Private repositories can control whether pull requests from forks can run workflows, and can configure the permissions assigned to GITHUB_TOKEN. For more information, see Administrar los ajustes de las GitHub Actions de un repositorio.
  • Las ejecuciones de flujos de trabajo que las solicitudes de incorporación de cambios de Dependabot desencadenan se ejecutan como si fueran de un repositorio bifurcado y, por lo tanto, usan un elemento GITHUB_TOKEN de solo lectura. Estas ejecuciones de flujo de trabajo no pueden acceder a ningún secreto. Para obtener información sobre las estrategias para mantener estos flujos de trabajo seguros, consulta Security hardening for GitHub Actions.

Modifying the permissions for the GITHUB_TOKEN

You can modify the permissions for the GITHUB_TOKEN in individual workflow files. If the default permissions for the GITHUB_TOKEN are restrictive, you may have to elevate the permissions to allow some actions and commands to run successfully. If the default permissions are permissive, you can edit the workflow file to remove some permissions from the GITHUB_TOKEN. As a good security practice, you should grant the GITHUB_TOKEN the least required access.

You can see the permissions that GITHUB_TOKEN had for a specific job in the "Set up job" section of the workflow run log. For more information, see Using workflow run logs.

You can use the permissions key in your workflow file to modify permissions for the GITHUB_TOKEN for an entire workflow or for individual jobs. This allows you to configure the minimum required permissions for a workflow or job.

Puede usar la clave permissions a fin de agregar y quitar permisos de lectura para repositorios bifurcados, pero normalmente no se puede conceder acceso de escritura. La excepción a este comportamiento es cuando un usuario administrador ha seleccionado la opción Enviar tokens a flujos de trabajo desde solicitudes de incorporación de cambios en la configuración de GitHub Actions. Para más información, consulta Administrar los ajustes de las GitHub Actions de un repositorio.

The two workflow examples earlier in this article show the permissions key being used at the job level, as it is best practice to limit the permissions' scope.

For full details of the permissions key, see Sintaxis del flujo de trabajo para GitHub Actions.

Nota:

Organization and enterprise owners can prevent you from granting write access to the GITHUB_TOKEN at the repository level. For more information, see Inhabilitar o limitar GitHub Actions para tu organización and Requerir políticas para las GitHub Actions en tu empresa.

When the permissions key is used, all unspecified permissions are set to no access, with the exception of the metadata scope, which always gets read access.

How the permissions are calculated for a workflow job

The permissions for the GITHUB_TOKEN are initially set to the default setting for the enterprise, organization, or repository. If the default is set to the restricted permissions at any of these levels then this will apply to the relevant repositories. For example, if you choose the restricted default at the organization level then all repositories in that organization will use the restricted permissions as the default. The permissions are then adjusted based on any configuration within the workflow file, first at the workflow level and then at the job level. Finally, if the workflow was triggered by a pull request from a forked repository, and the Send write tokens to workflows from pull requests setting is not selected, the permissions are adjusted to change any write permissions to read only.

Granting additional permissions

If you need a token that requires permissions that aren't available in the GITHUB_TOKEN, you can create a GitHub App and generate an installation access token within your workflow. For more information, see Realización de solicitudes de API autenticadas con una aplicación de GitHub en un flujo de trabajo de Acciones de GitHub. Alternatively, you can create a personal access token, store it as a secret in your repository, and use the token in your workflow with the ${{ secrets.SECRET_NAME }} syntax. For more information, see Administración de tokens de acceso personal and Using secrets in GitHub Actions.

Further reading