Identificación de los tokens de acceso admitidos

Completado

Aquí obtendrá información sobre los distintos tokens de acceso de GitHub y sus aplicaciones, limitaciones y límites de frecuencia.

Cuando se trata de conceder acceso a un usuario dentro de su empresa, la autenticación es increíblemente importante. El acceso de usuario debe tener un ámbito estricto e incluir solo lo que los usuarios necesiten para completar sus tareas. Comprender los distintos tokens de acceso es importante, ya que ayuda a guiar a los usuarios de la empresa para que usen la mejor opción para sus casos de uso.

GitHub usa varios tokens que permiten a los usuarios autenticarse en las distintas actividades que necesitan realizar. Normalmente, estos tokens son sencillos y es fácil saber qué token usar. Pero, a veces, se pueden usar varios tokens para lograr el mismo resultado, por lo que la elección de un token puede reducirse a tomar una buena decisión, una decisión mejor o la mejor decisión. En estas situaciones, es importante identificar las características de los tokens de GitHub y cómo determinar correctamente el ámbito del acceso de un token. Aquí se muestra una lista de los distintos tokens de acceso que hay disponibles:

• Tokens de acceso personal de GitHub
• Tokens de usuario a servidor de GitHub
• Tokens de servidor a servidor de GitHub
• Tokens de acceso de OAuth
• Tokens de actualización

Es importante animar al equipo de desarrollo a usar tokens con el ámbito adecuado para que, cuando se detecte una vulnerabilidad de seguridad, el riesgo se pueda mitigar rápidamente. Echemos un vistazo más de cerca a cada uno de estos tokens de acceso.

Tokens de acceso personal

Un token de acceso personal (PAT) es una alternativa al uso de una contraseña para la autenticación en GitHub. Para insertar y extraer datos de repositorios, GitHub debe comprobar el acceso de los usuarios. La comprobación se realiza a través de la dirección de correo electrónico comprobada de un usuario. Puede crear tantos tokens de acceso personal como requiera el flujo de trabajo y debe tratarlos con la misma seguridad que las contraseñas. Un procedimiento recomendado para la seguridad es usar tokens diferentes para aplicaciones diferentes. Para crear un token de acceso personal en GitHub, vaya a Configuración y, en Configuración del desarrollador, encontrará Tokens de acceso personal.

Puede establecer como ámbito de un token individual solo el acceso necesario para autenticar el trabajo para el que se asignará. El token está asociado a un usuario específico y se alinea con el acceso del usuario a la organización y a los repositorios. Puede revocar un token de acceso personal en cualquier momento, lo que es especialmente importante si se produce un ataque a la seguridad. Es importante comunicar al equipo que sus tokens de acceso personal deben tratarse con la misma seguridad que un nombre de usuario y una contraseña. Si un token se pone en peligro, debe tomar medidas de inmediato para revocarlo.

Los pasos detallados para crear un token de acceso personal están disponibles aquí: Creación de un token de acceso personal: Documentación de GitHub

Tokens de dispositivo

Un token de dispositivo es básicamente una versión de cuenta de equipo de un PAT que se usa en el contexto de un dispositivo y que proporciona acceso a un repositorio específico en casos de uso concretos que no están enlazados al usuario. Una configuración de aplicación mediante un flujo de OAuth usa un token de dispositivo. Normalmente se usan con ejecutores, servicios de aplicación especiales, trabajos cron (en Linux) u otros escenarios similares relacionados con tareas automatizadas. Al igual que el token de acceso personal, está vinculado a una cuenta individual y la cuenta para la que crea el token de dispositivo consume una licencia.

Tokens de instalación de aplicaciones de GitHub

Un token de instalación permite que una aplicación de GitHub realice solicitudes de API autenticadas para la instalación de la aplicación en una organización. Antes de crear un token de instalación, la aplicación de GitHub a la que se aplicará el token debe instalarse en el repositorio de destino. Los tokens de instalación son válidos durante 1 hora y son seguros, ya que se generan para un propósito concreto y expiran en una cantidad relativamente corta de tiempo.

Tokens de acceso de OAuth

Los tokens de OAuth2 se usan para autorizar a usuarios para las aplicaciones estándar de OAuth que se ejecutan en el explorador y para aplicaciones sin sentido, como las herramientas de la CLI. Permiten que la aplicación acceda a la API con un token de acceso de usuario. Estos tokens le permiten conectar su identidad de usuario de GitHub a aplicaciones de terceros, lo que permite a la aplicación realizar acciones en su nombre. Por ejemplo, si quiere usar una aplicación que solicita el ámbito user:email, la aplicación tendrá acceso de solo lectura a las direcciones de correo electrónico privadas. Estos tokens se pueden adquirir mediante el flujo de la aplicación web para aplicaciones de producción. Estos tokens también son seguros, dado que tienen una duración corta y expiran al cabo de 10 minutos.

Tokens de actualización

Un token de actualización se conecta con un token de OAuth. Cuando se concede un nuevo token de OAuth (mediante una solicitud de usuario a servidor), se incluye un token de actualización en la respuesta. Cuando el token de usuario expira, el token de actualización se puede intercambiar por un nuevo token de usuario con una solicitud de devolución de llamada. Cada vez que se emite un nuevo token de OAuth, se incluye un token de actualización. Los tokens de actualización son válidos durante seis meses y son un buen recordatorio para actualizar los tokens de OAuth.

Prefijos identificables

Como vemos en todo el sector, los prefijos de token son una manera clara de hacer que los tokens sean identificables. GitHub incluye tres prefijos de letra para representar cada token, que empiezan por un firmante de empresa, gh, seguido de la primera letra del tipo de token. Los resultados de los tipos de token anteriores son los siguientes:

• ghp para tokens de acceso personal de GitHub
• ghu para tokens de usuario a servidor de GitHub
• ghs para tokens de servidor a servidor de GitHub
• gho para tokens de acceso de OAuth
• ghr para tokens de actualización

Además, estos prefijos tienen un separador (_) dentro del token para mejorar la legibilidad. Un carácter de subrayado no es un carácter Base64, lo que ayuda a garantizar que cadenas generadas aleatoriamente como SHA no puedan duplicar accidentalmente estos tokens. Estos prefijos también ayudan a reducir la tasa de falsos positivos para el examen de secretos, que es una característica de seguridad avanzada de GitHub para mejorar aún más la seguridad dentro del repositorio de GitHub.

Límites de frecuencia de los tokens

Superar los límites de frecuencia puede provocar la pérdida de tiempo de desarrollo. Vamos a hablar de los límites de frecuencia de las aplicaciones de GitHub y las aplicaciones de OAuth. Comprender los límites de frecuencia le convierte en un recurso para los desarrolladores del equipo, ya que podrá ayudar a optimizar la inversión de la organización en estos recursos de GitHub.

Los límites de frecuencia ayudan a controlar la tasa de tráfico en GitHub y se basan en solicitudes por hora.

• Una aplicación de GitHub instalada en una cuenta de GitHub Enterprise tiene el límite de frecuencia de solicitudes en 15 000 solicitudes por hora.
• Una aplicación de OAuth se autentica en un usuario individual y está limitada a 5000 solicitudes por hora.

Para los administradores de Enterprise, debe supervisar los límites de frecuencia de las aplicaciones y trabajar con los desarrolladores para ajustar sus scripts para que permanezcan dentro de los límites. Normalmente, los límites de frecuencia no suponen un problema hasta que el desarrollador hace algo como escribir un script que solicita demasiada información en un flujo de trabajo. De repente, el desarrollo se detiene y los límites de frecuencia se convierten en un cuello de botella. Estos problemas de uso por encima del límite de frecuencia se pueden evitar si se limita el número de solicitudes por hora o se cambia un flujo de trabajo para que espere entre solicitudes. Si supera el límite de frecuencia mediante la autenticación básica u OAuth, es probable que pueda corregir el problema almacenando en caché las respuestas de la API y usando solicitudes condicionales.

Desde la consola de administración, puede configurar un límite de frecuencia personalizado para los usuarios no autenticados de la empresa y crear una lista de exenciones que permita a determinados usuarios usar el límite de frecuencia completo de la API.

Puede comprobar el estado actual del límite de frecuencia en cualquier momento mediante la API de límite de frecuencia siguiente. Los encabezados HTTP devueltos de cualquier solicitud de API muestran el estado actual del límite de frecuencia.

curl \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/rate_limit

Respuesta de ejemplo

{
  "resources": {
    "core": {
      "limit": 5000,
      "remaining": 4999,
      "reset": 1372700873,
      "used": 1
    },
    "search": {
      "limit": 30,
      "remaining": 18,
      "reset": 1372697452,
      "used": 12
    },
    "graphql": {
      "limit": 5000,
      "remaining": 4993,
      "reset": 1372700389,
      "used": 7
    },
    "integration_manifest": {
      "limit": 5000,
      "remaining": 4999,
      "reset": 1551806725,
      "used": 1
    },
    "code_scanning_upload": {
      "limit": 500,
      "remaining": 499,
      "reset": 1551806725,
      "used": 1
    }
  },
  "rate": {
    "limit": 5000,
    "remaining": 4999,
    "reset": 1372700873,
    "used": 1
  }
}

Para obtener información más detallada sobre los límites de frecuencia, consulte Limitación de la frecuencia en la Documentación de GitHub.