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

Obtenga toda la información necesaria 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 las credenciales del cliente: incluso cuando actúan en nombre de usuarios, necesitan acceder a una API web o a un recurso con su propia identidad por motivos técnicos. Un ejemplo es el acceso a los secretos de Azure Key Vault o Azure SQL Database de una caché.

Nota

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, por lo que un actor no válido no puede acceder a un secreto de cliente o un 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:

  • Son aplicaciones cliente confidenciales. Estas aplicaciones, dado que acceden a recursos con independencia de los usuarios, deben demostrar su identidad. También son aplicaciones bastante confidenciales. Tienen que ser aprobadas por los administradores de inquilinos de Azure Active Directory (Azure AD).
  • Han registrado un secreto (contraseña de la aplicación o certificado) en Azure AD. Este secreto se pasa durante la llamada a Azure AD para obtener un token.

Características específicas

Los usuarios no pueden interactuar con una aplicación de demonio. Una aplicación de demonio 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 Azure AD. 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 Azure AD. 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 dar su 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 Azure AD. 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 Azure AD durante el registro de la 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.