Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Servicios de Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Este artículo se centra en los patrones de autenticación de integración para aplicaciones, scripts y canalizaciones que llaman a Azure DevOps. Use la autenticación moderna basada en Microsoft Entra ID para las nuevas integraciones, ya que proporciona una mayor seguridad y una mejor compatibilidad a largo plazo.
Si necesita información general de nivel de organización que abarque el inicio de sesión del usuario, los controles de gobernanza y la posición de seguridad de nivel de plataforma, consulte Guía de autenticación para Azure DevOps.
Utilice la autenticación de Microsoft Entra ID para las nuevas aplicaciones que se integran con Azure DevOps Services. Use tokens de acceso personal con moderación y solo cuando Microsoft Entra ID no esté disponible.
Importante
Considere la posibilidad de usar los tokens más seguros de Microsoft Entra en lugar de los tokens de acceso personal de alto riesgo. Para obtener más información, consulte Reducir el uso de PAT. Revise las instrucciones de autenticación para elegir el mecanismo de autenticación adecuado para sus necesidades.
La autenticación de OAuth 2.0 y Microsoft Entra ID solo están disponibles para Azure DevOps Services, no para Azure DevOps Server.
Para escenarios locales, use bibliotecas cliente de .NET, autenticación de Windows o tokens de acceso personales.
Sugerencia
Puede usar la inteligencia artificial para ayudar con esta tarea más adelante en este artículo, o consulte Enable AI assistance with Azure DevOps MCP Server para empezar.
Comparación de las opciones de autenticación comunes
Use la tabla siguiente para comparar las opciones de autenticación más comunes para aplicaciones, scripts y canalizaciones.
| Method | Más adecuado para | Posición de seguridad | Administración de credenciales | Funciona con | Evitar cuándo |
|---|---|---|---|---|---|
| Identidad administrada | automatización hospedada Azure, como Azure Functions, App Service o máquinas virtuales | Opción más segura para cargas de trabajo hospedadas Azure porque los tokens son de corta duración y Azure administra el ciclo de vida de la identidad. | Ningún secreto de cliente para almacenar o girar; Azure administra la identidad y la adquisición de tokens | servicios de Azure DevOps; Azure cargas de trabajo hospedadas en el mismo inquilino de Microsoft Entra después de agregar la identidad a Azure DevOps | La carga de trabajo no se ejecuta en Azure o necesita una identidad portátil que no esté vinculada a un recurso de Azure. |
| Entidad principal de servicio | Automatización que se ejecuta fuera de Azure, en varios entornos o en sistemas de CI/CD externos | Opción segura al usar enfoques federados o de autenticación basados en certificados y aplicar privilegios mínimos | La identidad de la aplicación se administra y cualquier secreto de cliente o certificado, a menos que un flujo federado quite el secreto. | Azure DevOps Services; aplicaciones, scripts y servicios que necesitan una identidad de aplicación de Microsoft Entra | Puede usar una identidad administrada en su lugar para la misma carga de trabajo hospedada Azure o la herramienta solo admite la autenticación basada en PAT. |
| conexión de servicio Azure DevOps | Azure Pipelines acceso a recursos de Azure DevOps | Opción segura para la automatización de canalizaciones porque usa Microsoft Entra federación de identidades de carga de trabajo en lugar de tokens de larga duración | Azure DevOps administra la conexión de servicio y las canalizaciones no necesitan almacenar PAT en variables. | Azure DevOps Services; canalizaciones que acceden a repositorios, fuentes o API REST entre organizaciones | El escenario no se ejecuta a través de Azure Pipelines |
| Un token de acceso personal (PAT) | Scripts personales de corta duración, pruebas puntuales o escenarios heredados que aún no pueden usar la autenticación basada en Microsoft Entra | Mayor riesgo de las opciones comunes porque el token es un secreto de portador de larga duración vinculado a una cuenta de usuario | Debe crear, almacenar, rotar y revocar el token manualmente. | servicios y Azure DevOps Server de Azure DevOps; CLI, llamadas REST e integraciones heredadas que admiten PAT | La integración es un servicio de producción, una automatización compartida o cualquier escenario en el que haya disponible una entidad de servicio, una identidad administrada o una conexión de servicio. |
Recomendaciones rápidas
- Elija la identidad administrada en primer lugar cuando la carga de trabajo se ejecute en Azure y Azure pueda poseer el ciclo de vida de la identidad.
- Elija una entidad de servicio cuando necesite una identidad de aplicación, pero la carga de trabajo no se ejecuta en Azure o debe moverse entre entornos.
- Elija una conexión de servicio Azure DevOps cuando Azure Pipelines necesite acceder a los recursos de Azure DevOps sin pat.
- Elija un PAT solo para escenarios personales, temporales, heredados o Azure DevOps Server en los que no se apliquen las opciones más seguras.
Métodos de autenticación por escenario
Elija el método de autenticación adecuado en función del tipo de aplicación y los requisitos.
| Tipo de aplicación | Descripción | Ejemplo | Método recomendado | Ejemplos de código |
|---|---|---|---|---|
| Aplicaciones web o de escritorio | Aplicaciones interactivas que usan marcos actuales | Aplicación React, aplicación de escritorio de .NET | Microsoft Entra OAuth con la Biblioteca de Autenticación de Microsoft (MSAL) | Aplicación de consola cliente administrada |
| Aplicaciones de servicio o en segundo plano | Aplicaciones que se ejecutan sin interacción del usuario | Azure Functions, servicios en segundo plano | Entidades de servicio e identidades administradas | Entidades de servicio |
| Aplicaciones cliente heredadas | Aplicaciones existentes que usan bibliotecas cliente | Aplicaciones de consola con bibliotecas de Azure DevOps .NET | .NET bibliotecas de cliente con OAuth | Aplicación de consola de la biblioteca cliente |
| Aplicaciones sin interfaz gráfica de usuario (GUI) o con interfaz de línea de comandos (CLI) | Herramientas de línea de comandos no interactivas | Creación de scripts, herramientas de automatización | Flujo de concesión de autorización de dispositivos | Perfil de dispositivo |
| extensiones de Azure DevOps | Extensiones que se ejecutan en Azure DevOps | Widgets de panel personalizados y formularios de elementos de trabajo | SDK de extensión web Azure DevOps | Adición de un widget de panel |
| aplicaciones de Azure DevOps Server | Integraciones de Azure DevOps Server locales | Extensiones de servidor personalizadas | librerías de cliente .NET o autenticación de Windows | Aplicación de consola de la biblioteca cliente |
| Scripts personales o ad hoc | Scripts rápidos para uso personal | scripts de PowerShell, comandos de curl | Tokens de acceso personal | Introducción a las API REST |
| Azure Pipelines | Acceso a Azure DevOps desde la canalización | Consumo de artefactos de una organización diferente | conexión de servicio de Azure DevOps | Agregar una conexión de servicio de Azure DevOps Microsoft Entra |
Sugerencias para empezar
En las secciones siguientes se proporcionan recomendaciones para empezar a trabajar en diferentes escenarios.
Aplicaciones nuevas
- Cree integraciones de Azure DevOps con aplicaciones OAuth de Microsoft Entra para obtener la mejor seguridad y compatibilidad futura.
- Utilice principales de servicio o identidades administradas para casos de interacción entre servicios.
- Evite los tokens de acceso personal en aplicaciones de producción.
Aplicaciones existentes
- Planifique la migración de tokens de acceso personal a la autenticación de Microsoft Entra ID.
- Tenga en cuenta el cronograma de migración de autenticación como parte de las mejoras en Azure DevOps para reducir el uso de tokens de acceso personal.
- Revise el enfoque de autenticación actual con respecto a los procedimientos recomendados de seguridad.
Azure DevOps Server
- Utilice bibliotecas cliente de .NET con autenticación de Windows siempre que sea posible.
- Utiliza tokens de acceso personal para escenarios de Azure DevOps Server cuando lo permitan.
- Planee la migración futura de Azure DevOps Services para aprovechar las ventajas de la autenticación moderna.
Preguntas más frecuentes (FAQ)
¿Debo usar Microsoft Entra ID OAuth o tokens de acceso personal?
Use Microsoft Entra ID OAuth en los escenarios siguientes:
- Nuevas aplicaciones e integraciones.
- Cargas de trabajo de producción que requieren una seguridad sólida.
- Aplicaciones que necesitan integración de identidades empresariales.
- Proyectos a largo plazo con requisitos de cumplimiento.
Use tokens de acceso personal solo en los escenarios siguientes:
- Scripts personales y tareas ad hoc.
- Aplicaciones heredadas durante el planeamiento de la migración.
- Azure DevOps Server escenarios en los que la autenticación moderna no está disponible.
¿Debo usar las entidades de servicio o la delegación de usuarios para la autenticación?
Utilice entidades de servicio o identidades administradas en los escenarios siguientes:
- Cree aplicaciones que funcionen de forma independiente (servicios en segundo plano, automatización).
- Cree aplicaciones que no requieran interacción del usuario.
- Implemente la comunicación entre servicios.
- Cree canalizaciones de integración continua y entrega continua (CI/CD) o flujos de trabajo automatizados.
Use la delegación de usuarios (OAuth con consentimiento del usuario) en los escenarios siguientes:
- Cree aplicaciones que actúen para los usuarios humanos.
- Cree aplicaciones interactivas en las que los usuarios inicien sesión con sus propias credenciales.
- Implemente características que requieran permisos específicos del usuario.
- Cree aplicaciones que respeten los derechos de acceso individuales de los usuarios.
¿Cómo se autentica con Azure DevOps Services y Azure DevOps Server?
Cree rutas de autenticación independientes para cada servicio:
- Azure DevOps Services: use Microsoft Entra ID OAuth.
- Azure DevOps Server: Use bibliotecas cliente de .NET con autenticación de Windows o tokens de acceso personales.
Use el requestContext método para detectar el tipo de servicio y aplicar el método de autenticación adecuado.
¿Por qué mi cuenta de servicio no puede acceder a las API de Azure DevOps?
Estos son algunos problemas comunes que afectan al acceso a la cuenta de servicio:
- Cuenta de servicio no "materializada": use el método de inicio de sesión correcto. Las cuentas de servicio necesitan permisos de inicio de sesión interactivos o un registro de Microsoft Entra ID adecuado.
- Permisos insuficientes: asegúrese de que la cuenta de servicio tenga los permisos de Azure DevOps adecuados.
- Método de autenticación: use entidades de servicio o identidades administradas en lugar de intentar autenticarse como una cuenta de servicio.
¿Cómo puedo migrar de tokens de acceso personal a la autenticación moderna?
Siga estos pasos:
Identifique el uso actual del token de acceso personal en las aplicaciones.
Elija un método de autenticación alternativo:
- Microsoft Entra ID OAuth para escenarios delegados por el usuario
- Entidades de servicio para escenarios de servicio a servicio
- conexión de servicio Azure DevOps
Actualice el código de autenticación mediante los ejemplos de autenticación de migración de Azure DevOps.
Pruebe los cambios exhaustivamente antes de eliminar las dependencias de tokens personales de acceso.
Supervise y valide el nuevo método de autenticación.
¿Por qué no debo decodificar ni leer reclamaciones de tokens de autenticación?
Los tokens de autenticación existen únicamente para demostrar quién es el autor de la llamada y qué están autorizados a hacer. No son una interfaz de datos estable o un esquema en el que puede depender.
Las afirmaciones de token nunca se documentan públicamente, y Azure DevOps se reserva el derecho de modificar, cambiar el nombre, quitar o cifrarlas en cualquier momento sin previo aviso. A partir del verano de 2025, Azure DevOps está cifrando aún más los tokens de autenticación, lo que significa que los clientes no pueden leer cargas de tokens. Cualquier aplicación que decodifique tokens para extraer reclamaciones se rompe.
En lugar de leer reclamaciones de token, siga estos procedimientos:
- Tratar tokens como opacos : páselos en encabezados de autorización, pero no descodifique ni inspeccione.
- Use las API REST admitidas: recupere datos de usuario u organización de las API REST de Azure DevOps, que proporcionan contratos y documentación estables.
- Supongamos que cualquier declaración puede cambiar — si se encuentra analizando el contenido del token para leer valores, integre esa lógica en una llamada API.
Estos cambios no afectan a las aplicaciones que ya tratan los tokens como opacos.
Procedimientos de implementación
Después de elegir el método de autenticación para su escenario, complete los pasos de implementación:
- Nuevas aplicaciones: Desarrollar integraciones de Azure DevOps con aplicaciones de Microsoft Entra OAuth
- Aplicaciones de servicio: Usar entidades de servicio e identidades administradas en Azure DevOps
- Scripts personales: Usar tokens de acceso personal
- Azure Pipelines: Accede a Azure DevOps utilizando la identidad de carga de trabajo de Entra
El uso de IA para elegir un método de autenticación
Si conecta el Azure DevOps servidor MCP al agente de IA en modo de agente, puede usar mensajes de lenguaje natural para obtener recomendaciones de autenticación para su escenario.
| tarea | Mensaje de ejemplo |
|---|---|
| Elección de la autenticación para un servicio en segundo plano | Which authentication method should I use for a background Azure Function that needs to access Azure DevOps APIs? |
| Comparación de las opciones de autenticación | Help me choose between service principals, managed identities, and personal access tokens for my Azure DevOps integration |
| Autenticación para una aplicación web | I'm building a React web app that needs to access Azure DevOps on behalf of signed-in users — what authentication approach should I use? |
| Migración desde PAT | Help me plan a migration from personal access tokens to Microsoft Entra ID authentication for my Azure DevOps integrations |
| Autenticación para CI/CD | What's the most secure way to authenticate Azure DevOps REST API calls from a GitHub Actions workflow? |
| Solución de problemas de errores de autenticación | I'm getting 401 errors when calling the Azure DevOps REST API with my token — help me diagnose the issue |
Nota:
El modo de agente y el servidor MCP usan lenguaje natural, por lo que puede ajustar estas indicaciones o formular preguntas de seguimiento para refinar los resultados.