Si es posible, considera la creación de una App en lugar de una OAuth app. En general, se prefieren las Apps frente a las OAuth apps. Las Apps usan permisos específicos, proporcionan al usuario más control sobre los repositorios a los que puede acceder la aplicación y usan tokens de corta duración. Estas propiedades pueden mejorar la seguridad de la aplicación, ya que limitan el daño que se causaría si se filtrasen las credenciales de la aplicación.
De forma similar a las OAuth apps, las Apps pueden usar de todos modos OAuth 2.0, generar un tipo de token de OAuth (denominado token de acceso de usuario) y realizar acciones en nombre de un usuario. No obstante, las Apps también pueden actuar de manera independiente del usuario.
Para más información sobre las Apps, consulta Acerca de la creación de Apps.
Para más información sobre cómo migrar una OAuth app existente a una App, consulta Migración de aplicaciones de OAuth a aplicaciones de .
La OAuth app solo debe solicitar los ámbitos que la aplicación necesita para realizar su funcionalidad prevista. Si alguno de los tokens de la aplicación está en peligro, con esto se limitará la cantidad de daños que pueden producirse. Para más información, consulta Autorización de aplicaciones de OAuth.
Después de iniciar sesión en un usuario, los desarrolladores de aplicaciones deben realizar pasos adicionales para asegurarse de que el usuario está pensado para tener acceso a los datos del sistema. Cada inicio de sesión requiere comprobaciones nuevas en torno a sus pertenencias, acceso y su estado actual de SSO.
Cuando un usuario inicia sesión y realiza acciones en la aplicación, debe recordar qué usuario realizó esa acción para concederles acceso a los mismos recursos la próxima vez que inicien sesión.
Para almacenar los usuarios en la base de datos correctamente, use siempre el id del usuario. Este valor nunca cambiará para el usuario o se usará para que apunte a otro usuario, por lo que garantiza que proporciona acceso al usuario correcto. Puedes encontrar el id de un usuario con el punto de conexión de la API de REST GET /user. Consulta Puntos de conexión de la API de REST para usuarios.
Si almacena referencias a repositorios, organizaciones y empresas, use también sus id para asegurarse de que los vínculos a ellos sigan siendo precisos.
Nunca use identificadores que puedan cambiar con el tiempo, incluidos los identificadores de usuario, los campos de datos dinámicos de la organización o las direcciones de correo electrónico.
Al iniciar sesión en un usuario, debes realizar un seguimiento de las organizaciones para las que está autorizado el token del usuario. Esto puede cambiar con el tiempo después de iniciar sesión a medida que los usuarios se quitan de las organizaciones. Si una organización usa el inicio de sesión único de SAML y un usuario no lo ha realizado, el token de acceso de usuario no tendrá acceso a esa organización. Debes usar el punto de conexión de la API de REST de GET /user/installations para comprobar con regularidad a qué organizaciones tiene acceso un token de acceso de usuario. Si el usuario no está autorizado a acceder a una organización, debe impedir su acceso a los datos propiedad de la organización dentro de su propia aplicación hasta que realice el SSO de SAML o vuelva a unirse a la organización. Para más información, consulta Puntos de conexión de la API de REST para instalaciones de Apps.
Además del seguimiento de la identidad de usuario a través del campo id, debe conservar los datos de la organización o de la empresa en la que cada usuario está funcionando. Esto le ayudará a asegurarse de que no filtre información confidencial si un usuario cambia los roles.
Por ejemplo:
- Un usuario está en la organización
Mona, que requiere el inicio de sesión único de SAML e inicia sesión en la aplicación después de realizar el inicio de sesión único. La aplicación ahora tiene acceso a lo que haga el usuario dentro deMona. - El usuario extrae un montón de código de un repositorio en
Monay lo guarda en la aplicación para su análisis. - Más adelante, el usuario cambia los trabajos y se quita de la organización
Mona.
Cuando el usuario accede a la aplicación, ¿puede ver el código y el análisis de la organización Mona en su cuenta de usuario?
Este es el motivo por el que es fundamental realizar un seguimiento del origen de los datos que guarda la aplicación. De lo contrario, la aplicación es una amenaza de protección de datos para las organizaciones y es probable que prohibieran la aplicación si no pueden confiar en que la aplicación protege correctamente sus datos.
Los usuarios externos a la organización o la enterprise pueden acceder a la aplicación OAuth. Si pretende que una aplicación solo la usen los miembros de su organización o enterprise, debe comprobar el estado de la suscripción del usuario cuando el usuario inicie sesión en la aplicación.
Para buscar la lista de organizaciones de las que un usuario es miembro, puede usar el punto de conexión "Enumerar organizaciones para el usuario autenticado". A continuación, puede validar esta lista en una lista de organizaciones aprobadas para la aplicación. Para más información, consulta Puntos de conexión de API REST para organizaciones.
Con un secreto de cliente, la aplicación puede autorizar a un usuario y generar tokens de acceso de usuario. Estos tokens se pueden usar para realizar solicitudes de API en nombre de un usuario.
Debes almacenar el secreto de cliente de la aplicación y los tokens generados de forma segura. El mecanismo de almacenamiento depende de la arquitectura de las integraciones y de la plataforma en la que se ejecuta. Por lo general, debes usar un mecanismo de almacenamiento pensado para almacenar datos confidenciales en la plataforma que estés usando.
Si la aplicación es un sitio web o una aplicación web, considera la posibilidad de almacenar el secreto de cliente en un almacén de claves como Azure Key Vault, o como una variable de entorno cifrada o un secreto en el servidor.
Si la aplicación es un cliente nativo, una aplicación del lado cliente o se ejecuta en un dispositivo de usuario (en lugar de ejecutarse en los servidores), no puedes proteger el secreto de cliente. Debes tener cuidado si planeas acceder a tus propios servicios en función de los tokens generados por la aplicación, ya que cualquier usuario puede acceder al secreto de cliente para generar un token.
Si la aplicación es un sitio web o una aplicación web, debes cifrar los tokens en el back-end y garantizar que haya seguridad en los sistemas que pueden acceder a los tokens. Considere la posibilidad de almacenar tokens de actualización en un lugar independiente de los tokens de acceso activos.
Si la aplicación es un cliente nativo, aplicación del lado cliente o se ejecuta en un dispositivo de usuario (en lugar de ejecutarse en tus servidores), es posible que no puedas proteger los tokens igual de bien que en una aplicación que se ejecuta en los servidores. Debes almacenar tokens a través del mecanismo recomendado para la plataforma de la aplicación y tener en cuenta que es posible que el mecanismo de almacenamiento no sea totalmente seguro.
Las OAuth apps pueden generar tokens de acceso de usuario para realizar solicitudes de API autenticadas. La aplicación nunca debe usar una contraseña de personal access token o para autenticarse.
Debes tener un plan implementado para poder controlar las infracciones de seguridad de forma oportuna.
En caso de que el secreto de cliente de tu aplicación esté en peligro, tendrás que generar un nuevo secreto, actualizar la aplicación para que utilice el nuevo secreto y eliminar el antiguo.
En caso de que los tokens de acceso de usuario estén en peligro, debes revocar inmediatamente estos tokens. Para más información, consulta Puntos de conexión de la API de REST para las autorizaciones de OAuth.
Debes realizar exámenes de vulnerabilidades regulares para la aplicación. Por ejemplo, puedes configurar el examen de código y el examen de secretos para el repositorio que hospeda el código de la aplicación. Para más información, consulta Acerca del examen de código y Acerca del examen de secretos.
Si la aplicación se ejecuta en un servidor, comprueba que el entorno del servidor es seguro y que puedes controlar el volumen de tráfico esperado de la aplicación.
Si la aplicación usa servicios de terceros, se deben usar de forma segura:
- Los servicios usados por la aplicación deben tener un inicio de sesión y una contraseña únicos.
- Las apps no deben compartir cuentas de servicio tales como servicios de correo electrónico o de bases de datos para administrar tu servicio SaaS.
- Solo los empleados con tareas administrativas deben tener acceso de administrador a la infraestructura que hospeda la aplicación.
Considere la posibilidad de agregar funcionalidades de registro y supervisión para la aplicación. Un registro de seguridad debería incluir:
- Eventos de autenticación y autorización
- Cambios a la configuración del servicio
- Escritura y lectura de objetos
- Los cambios de permisos de usuarios y grupos
- Elevación de rol a aquel de administrador
Los registros deben usar marcas de tiempo coherentes para cada evento y registrar los usuarios, las direcciones IP o los nombres de host de todos los eventos registrados.
Si tu aplicación está disponible para otros usuarios, debes darles la posibilidad de eliminar sus datos. Los usuarios no deben tener que enviar un correo electrónico ni llamar a una persona de soporte técnico para eliminar sus datos.