En general, se prefieren las Apps antes que las OAuth apps.
Tanto las OAuth apps como las Apps usan OAuth 2.0.
Las OAuth apps solo pueden actuar en nombre de un usuario, mientras que las Apps pueden actuar en nombre de un usuario o con independencia de él.
Para más información, consulta Diferencias entre aplicaciones de y aplicaciones de OAuth.
Para información sobre cómo migrar una OAuth app existente a una App, consulta Migración de aplicaciones de OAuth a aplicaciones de .
Las Apps proporcionan más control sobre lo que puede hacer la aplicación. En lugar de los ámbitos amplios que usan las OAuth apps, las Apps emplean permisos específicos. Por ejemplo, si tu aplicación necesita leer el contenido de un repositorio, una OAuth app requeriría el ámbito repo, que también permitiría a la aplicación editar la configuración y el contenido del repositorio. Una App puede solicitar acceso de solo lectura al contenido del repositorio, el que no permitirá que la aplicación realice acciones que necesiten más privilegios, como editar la configuración o el contenido del repositorio.
Las Apps también ofrecen más control sobre el acceso al repositorio. Con una App, el propietario de la organización o el usuario que instaló la aplicación puede decidir a qué repositorios puede acceder la aplicación. Por el contrario, una OAuth app puede acceder a cada repositorio a los que puede acceder el usuario que autorizó la aplicación.
Las Apps utilizan tokens de corta duración. Si se filtra el token, será válido durante un período más breve, lo que reduce el daño que pueda haber. Por el contrario, los tokens de una OAuth app no expiran hasta que la persona que autorizó la OAuth app los revoca.
Estas características de seguridad ayudan a proteger la seguridad de App al limitar el daño que se podría hacer si se hubieran filtrado las credenciales de la aplicación. Además, esto permite que las organizaciones con directivas de seguridad más estrictas usen la aplicación.
Las Apps pueden actuar de manera independiente de un usuario. Esto resulta beneficioso para las automatizaciones que no requieren la entrada del usuario.
De manera similar a lo que ocurre con las OAuth apps, las Apps pueden realizar de todos modos acciones en nombre de un usuario. A diferencia de lo que ocurre con las OAuth apps, que no indican que la aplicación hizo la acción, las Apps indican que la aplicación hizo la acción en nombre del usuario.
Las instancias de Apps no están vinculadas a una cuenta de usuario y no consumen una licencia. Las Apps permanecen instaladas aunque la persona que instaló inicialmente la aplicación deje la organización. Esto permite que las integraciones sigan funcionando incluso si las personas dejan el equipo.
El límite de frecuencia de las Apps con un token de acceso de instalación se escala con el número de repositorios y el número de usuarios de la organización. Por el contrario, las OAuth apps tienen límites de frecuencia inferiores y no se escalan. Para más información, consulta Límites de frecuencia para aplicaciones de .
Las Apps tienen webhooks centralizados integrados. Las Apps pueden recibir eventos de webhook de todos los repositorios y organizaciones a los que pueda acceder la aplicación. Por el contrario, las OAuth apps deben configurar webhooks de manera individual para cada repositorio y organización.
En general, las Apps y las OAuth apps pueden hacer las mismas solicitudes de API. Sin embargo, hay algunas diferencias:
- La API REST para administrar las ejecuciones de comprobación y los conjuntos de comprobación solo está disponible para las Apps.
- Los recursos de nivel empresarial, como el propio objeto de empresa, no están disponibles para las Apps. Esto significa que las Apps no pueden llamar a puntos de conexión como
GET /enterprise/settings/license. Sin embargo, hay disponibles recursos de repositorio y de organización propiedad de la empresa. - Algunas solicitudes pueden devolver datos incompletos en función de los permisos y el acceso al repositorio que se concedió a una App. Por ejemplo, si la aplicación realiza una solicitud para obtener todos los repositorios a los que un usuario puede acceder, la respuesta solo incluirá los repositorios a los que también se concedió acceso a la aplicación.
Para más información sobre los puntos de conexión de API REST que están disponibles para las Apps, consulta Puntos de conexión disponibles para tokens de acceso de instalación de aplicaciones de .
Si quieres acceder a los recursos de en nombre de un usuario o una organización, o si prevés una integración de larga duración, te recomendamos compilar una App.
Puedes usar personal access tokens para scripts de corta duración o pruebas de API. Como personal access token está asociado a un usuario, la automatización podría interrumpirse si el usuario ya no tiene acceso a los recursos que necesita. Una App instalada en una organización no depende de un usuario. Además, a diferencia de un usuario, App no consume una licencia.
admite dos tipos de personal access tokens, pero te recomienda usar fine-grained personal access token, siempre que sea posible, en lugar de personal access tokens (classic). Para más información sobre personal access tokens, consulta Administración de tokens de acceso personal.
Tanto Apps como Actions proporcionan formas de crear herramientas de automatización y flujo de trabajo.
Actions proporcionan automatización de trabajos, como integración continua, tareas de implementación y administración de proyectos de un repositorio. Se ejecutan directamente en máquinas ejecutoras hospedadas en o ejecutores autohospedados que el administrador configura. Actions no se ejecutan de manera persistente, Los flujos de trabajo de Actions se ejecutan en respuesta a eventos que se producen en su repositorio y solo tienen acceso a los recursos del repositorio para el que están configurados. Sin embargo, se pueden compartir acciones personalizadas entre repositorios y organizaciones, lo que permite a los desarrolladores reutilizar y modificar las acciones existentes para satisfacer sus necesidades. Actions también incluyen la administración de secretos integrada, que puedes usar para interactuar de manera segura con servicios de terceros y administrar con seguridad las claves de implementación.
Apps se ejecutan de forma persistente en una infraestructura de servidor o proceso que proporciones o ejecutes en un dispositivo de usuario. Pueden reaccionar a los eventos de webhook de , así como a los eventos de fuera del ecosistema de . Son una buena opción para las operaciones que abarcan varios repositorios u organizaciones, o para proporcionar servicios hospedados a otras organizaciones. Una instancia de App es la mejor opción al crear una herramienta con funciones que se tienen lugar principalmente fuera de o que requieren más tiempo de ejecución o permisos de los que asigna un flujo de trabajo de Actions.
Para más información sobre cómo se comparan Actions y Apps, consulta Acercad e las acciones personalizadas.
Puedes usar App para autenticarte en un flujo de trabajo de Actions si el _TOKEN integrado no tiene permisos suficientes. Para más información, consulta Realización de solicitudes de API autenticadas con una aplicación de en un flujo de trabajo de Acciones de .