Ámbitos para las aplicaciones de OAuth

Al configurar un OAuth app en GitHub, los ámbitos solicitados se muestran al usuario en el formulario de autorización.

Si tu OAuth app no tiene acceso a un buscador, tal como una herramienta de CLI, entonces no necesitarás especificar un alcance para que los usuarios se autentiquen dicha app. Para más información, consulta Autorización de aplicaciones de OAuth.

Verifica los encabezados para ver qué permisos de OAuth tienes, y qué acepta la acción de la API.

$ curl -H "Authorization: Bearer OAUTH-TOKEN" http(s)://HOSTNAME/api/v3/users/codertocat -I
HTTP/2 200
X-OAuth-Scopes: repo, user
X-Accepted-OAuth-Scopes: user

•         `X-OAuth-Scopes` enumera los alcances que el token ha autorizado.
  

•         `X-Accepted-OAuth-Scopes` enumera los ámbitos que comprueba la acción.
  

Ámbitos disponibles

          **Nota**: Además de los recursos relacionados con el repositorio, el ámbito `repo` también concede acceso para administrar recursos propiedad de la organización, incluidos proyectos, invitaciones, pertenencias a equipos y webhooks. Este ámbito también concede la capacidad de administrar proyectos propiedad de los usuarios.

 repo:status| Otorga acceso de lectura/escritura a los estados de confirmación en los repositorios públicos y privados, privados e internos. Este alcance solo se necesita para otorgar acceso a otros usuarios o servicios a los estados de las confirmaciones en repositorios privados sin otorgarles acceso al código.  repo_deployment| Concede acceso a los estados de implementación para repositorios públicos y privados. Este alcance solo se necesita para otorgar acceso a otros usuarios o servicios a los estados de implementación, sin otorgarles acceso al código.  public_repo| Limita el acceso a los repositorios públicos. Esto incluye el acceso de lectura/escritura al código, estados de confirmación, proyectos de repositorios, colaboradores y estados de despliegue para repositorios públicos y organizaciones. También es necesario para marcar con estrella los repositorios públicos.  repo:invite | Otorga permiso para aceptar o rechazar invitaciones para colaborar en un repositorio. Este ámbito solo es necesario para otorgar acceso a otros usuarios o servicios a las invitaciones sin otorgar acceso al código.  security_events | Concesiones:
acceso de lectura y escritura a eventos de seguridad en la API de code scanning
Este ámbito solo se necesita para otorgar acceso a otros usuarios o servicios a los eventos de seguridad sin otorgarles acceso al código. admin:repo_hook | Otorga acceso de lectura, escritura, ping y eliminación a los enlaces en repositorios públicos, privados o internos. Los ámbitos repo y public_repo conceden acceso total a los repositorios, incluidos los enlaces de repositorio. Use el alcance admin:repo_hook para limitar el acceso solo a los enlaces de repositorio.  write:repo_hook | Otorga acceso de lectura, escritura y ping a los enlaces en repositorios públicos, privados o internos.  read:repo_hook| Otorga acceso de lectura y ping a los enlaces en repositorios públicos, privados o internos. admin:org | Gestiona completamente la organización, sus equipos, proyectos y miembros.  write:org| Acceso de lectura y escritura a los miembros de la organización y a los proyectos de la organización.  read:org| Acceso de solo lectura a la membresía de la organización, los proyectos de la organización y la membresía en equipos. admin:public_key | Administre totalmente las claves públicas.  write:public_key| Cree, enumere y vea los detalles de claves públicas.  read:public_key| Enumere y vea los detalles de claves públicas. admin:org_hook | Otorga acceso de lectura, escritura, ping y borrado a los enlaces de la organización. Nota: Los tokens de OAuth solo podrán realizar estas acciones en los ganchos de organización que hayan sido creados por la OAuth app. Un Personal access token solo podrá llevar a cabo estas acciones en los ganchos de la organización que cree un usuario. gist | Otorga acceso de escritura a los gists. notifications | Concesiones:
acceso de lectura a las notificaciones del usuario
acceso de marcación y lectura a subprocesos
acceso de inspección y anulación de inspección de un repositorio
acceso de lectura, escritura y eliminación a suscripciones de subprocesos user | Otorga acceso de lectura/escritura únicamente a la información de perfiles. Tenga en cuenta que este alcance incluye user:email y user:follow.  read:user| Otorga acceso para leer los datos del perfil de un usuario.  user:email| Otorga acceso de lectura a las direcciones de correo electrónico de un usuario.  user:follow| Otorga acceso para seguir o no seguir a otros usuarios. delete_repo | Otorga acceso para borrar los repositorios administrables. write:packages | Otorga acceso para cargar o publicar un paquete en GitHub Packages. Para más información, consulta Publicación de un paquete. read:packages | Otorga acceso para descargar o instalar paquetes desde GitHub Packages. Para más información, consulta Instalación de un paquete. delete:packages | Otorga acceso para eliminar paquetes de GitHub Packages. Para más información, consulta Borrar y restablecer un paquete. admin:gpg_key | Administración completa de claves de GPG.  write:gpg_key| Cree, enumere y consulte los detalles de las claves GPG.  read:gpg_key| Enumere y vea los detalles de las claves de GPG. workflow | Concede la capacidad de agregar y actualizar archivos de flujo de trabajo de GitHub Actions. Los archivos de flujo de trabajo pueden registrarse sin este permiso si el mismo archivo (con la misma ruta y contenido) existe en otra rama del mismo repositorio. Los archivos de flujo de trabajo pueden exponer GITHUB_TOKEN, que pueden tener un conjunto diferente de alcances. Para obtener más información, consulta Uso de GITHUB_TOKEN para la autenticación en flujos de trabajo. admin:enterprise | Proporciona control total de la funcionalidad empresarial. Para obtener más información, consulta Administrar cuentas empresariales en la documentación de la API de GraphQL.

Incluye manage_runners:enterprise, manage_billing:enterprise y read:enterprise.  manage_runners:enterprise | Proporciona control total sobre los ejecutores autohospedados dentro de la empresa. Para más información, consulta Ejecutores autohospedados.  manage_billing:enterprise | Lectura y escritura de datos de facturación de la empresa. Para más información, consulta Puntos de conexión de la API de REST para la facturación.  read:enterprise | Consultar todos los datos de un perfil empresarial. No incluye los datos de perfil de los miembros de la empresa o las organizaciones. read:audit_log | Lee los datos del registro de auditoría.

https://github.com/login/oauth/authorize?
  client_id=...&
  scope=user%20repo_deployment

Alcances solicitados y otorgados

El atributo scope enumera los alcances vinculados al token que otorgó el usuario. Normalmente, estos alcances serán idénticos a lo que solicitaste. Sin embargo, los usuarios pueden editar sus alcances, efectivamente otorgando a la aplicación menos acceso del que solicitaste originalmente. Además, los usuarios pueden editar los alcances de los tokens después de completar un flujo de OAuth. Debe conocer esta posibilidad y ajustar el comportamiento de la aplicación en consecuencia.

Es importante gestionar los casos de error en donde un usuario elige otorgarle menos acceso del que solicitó en un principio. Por ejemplo, las aplicaciones pueden advertir o comunicar de cualquier otra forma a sus usuarios que se ha reducido el rendimiento o que no son capaces de realizar alguna acción.

Además, las aplicaciones siempre pueden redirigir a los usuarios a través del flujo para obtener permisos adicionales, pero no olvide que dichos usuarios siempre pueden negarse a hacerlo.

Consulte la Guía de aspectos básicos de la autenticación, que proporciona sugerencias sobre cómo controlar alcances de tokens modificables.

Alcances normalizados

Cuando se solicitan varios alcances, el token se guarda con una lista de alcances normalizada y se descartan aquellos que se incluyen de manera implícita en otro alcance solicitado. Por ejemplo, la solicitud user,gist,user:email dará como resultado un token con únicamente los alcances user y gist, porque el acceso concedido con el alcance user:email se incluye en el alcance user.