Escenario: Aplicación de demonio que llama a las API web

Este escenario le guiará para compilar una aplicación de demonio que llama a las API web.

Información general

La aplicación puede adquirir un token para llamar a una API web en nombre propio (no en el nombre de un usuario). Este escenario es útil para aplicaciones de demonio. Usa la concesión de credenciales del cliente OAuth 2.0 estándar.

Daemon apps

Estos son algunos ejemplos de casos de usos para aplicaciones de demonio;

  • Aplicaciones web que se usan para aprovisionar o administrar usuarios, o llevar a cabo procesos por lotes en un directorio
  • Aplicaciones de escritorio (como servicios de Windows en Windows o procesos de demonio en Linux) que realizan trabajos por lotes, o un servicio de sistema operativo que se ejecuta en segundo plano
  • API Web que necesitan manipular directorios, no usuarios específicos

Hay otro caso habitual en el que las aplicaciones que no son demonios usan credenciales de cliente, incluso cuando actúan en nombre de usuarios. Esto ocurre cuando necesitan acceder a una API web o un recurso bajo su propia identidad por razones técnicas. Un ejemplo es el acceso a los secretos de Azure Key Vault o Azure SQL Database de una caché.

No se puede implementar una aplicación de demonio en el dispositivo de un usuario normal, y un usuario normal no puede acceder a una aplicación de demonio. Solo un conjunto limitado de administradores de TI puede acceder a los dispositivos que tienen aplicaciones de demonio en ejecución. De esta manera, los actores no válido no puede acceder a ningún secreto de cliente o token desde el tráfico del dispositivo, ni actuar en nombre de la aplicación de demonio. El escenario de la aplicación de demonio no reemplaza la autenticación del dispositivo.

Ejemplos de aplicaciones que no son de demonio:

  • Una aplicación móvil que accede a un servicio web en nombre de una aplicación, pero no en nombre de un usuario.
  • Un dispositivo IoT que accede a un servicio web en nombre de un dispositivo, pero no en nombre de un usuario.

Las aplicaciones que adquieren un token para sus propias identidades:

  • Las aplicaciones cliente confidenciales, dado que acceden a recursos con independencia de los usuarios, deben demostrar su identidad. Los administradores de inquilinos de Microsoft Entra deben conceder aprobación a estas aplicaciones bastante confidenciales.
  • Han registrado un secreto (contraseña de la aplicación o certificado) en Microsoft Entra ID. Este secreto se pasa durante la llamada a Microsoft Entra ID para obtener un token.

Características específicas

Los usuarios no pueden interactuar con una aplicación de demonio porque requiere su propia identidad. Este tipo de aplicación solicita un token de acceso mediante su identidad de aplicación y presenta el identificador de aplicación, las credenciales (contraseña o certificado) y el URI del identificador de aplicación a Microsoft Entra ID. Tras una autenticación correcta, el demonio recibe un token de acceso (y un token de actualización) de la Plataforma de identidad de Microsoft. Este token se usa luego para llamar a la API web (y se actualiza según sea necesario).

Dado que los usuarios no pueden interactuar con aplicaciones de demonio, no es posible el consentimiento incremental. Todos los permisos de API necesarios deben configurarse en el registro de aplicación. El código de la aplicación simplemente solicita permisos definidos de forma estática. Esto también significa que las aplicaciones de demonio no admiten el consentimiento incremental.

Para los desarrolladores, la experiencia total de este escenario tiene los siguientes aspectos:

  • Las aplicaciones de demonio solo pueden funcionar en inquilinos de Microsoft Entra. No tendría sentido crear una aplicación de demonio que intentara manipular cuentas personales de Microsoft. Si es desarrollador de aplicaciones de línea de negocio (LOB), creará la aplicación de demonio en el inquilino. Si es fabricante de software independiente, es posible que quiera crear una aplicación de demonio de varios inquilinos. Cada administrador de inquilinos debe proporcionar consentimiento.
  • Durante el registro de aplicación, no se necesita el URI de respuesta. Comparta secretos o certificados, o instrucciones de aserción firmadas, con Microsoft Entra ID. También debe solicitar permisos de aplicación y otorgar consentimiento del administrador para usar esos permisos de aplicación.
  • La configuración de la aplicación tiene que proporcionar las credenciales de cliente como compartidas con Microsoft Entra ID durante el registro de aplicación.
  • El ámbito usado para adquirir un token con el flujo de credenciales del cliente debe ser un ámbito estático.

Si no está familiarizado con la administración de identidades y acceso (IAM) con OAuth 2.0 y OpenID Connect, o incluso si es nuevo en IAM en la plataforma de identidad de Microsoft, debe dar máxima prioridad a leer los siguientes artículos.

Aunque su lectura no es necesaria antes de completar el primer inicio rápido o tutorial, se tratan temas fundamentales para la plataforma, y estar familiarizado con ellos le ayudará a medida que crea escenarios más complejos.

Pasos siguientes

Avance al siguiente artículo de este escenario, Registro de la aplicación.