Llamada a una API desde otra API

¿Cómo puede garantizar una Confianza cero, como desarrollador, cuando tiene una API que necesita llamar a otra API? En este artículo, aprenderá a desarrollar de forma segura la aplicación cuando se trabaja en nombre de un usuario.

Cuando un usuario controla la interfaz de una aplicación, la aplicación puede usar un permiso delegado para que la API sepa en nombre de qué usuario se está ejecutando. Inspecciona las notificaciones de asunto (sub) o de identificador de objeto (oid) e identificador de inquilino (tid) en el token de acceso que proporciona la aplicación al llamar a la API. La API no se basa en la aplicación que no es de confianza, que es solo una llamada que proviene de algún lugar de la red. En su lugar, valida el token para asegurarse de que la API solo funciona en nombre del usuario de la aplicación que Microsoft Entra ID comprobó.

Cuando una API (a la que nos referimos como la API original) llama a otra, es vital que la API a la que estamos llamando (nos referimos a ella como la API descendente) siga el proceso de validación. La API de bajada no puede confiar en una fuente de red que no sea de confianza. Debe obtener la identidad del usuario de un token de acceso validado correctamente.

Si la API de bajada no sigue el proceso de validación adecuado, debe confiar en la API original para proporcionar la identidad del usuario de otra manera. La API de bajada podría usar incorrectamente un permiso de aplicación para realizar esta operación. A continuación, la API original se convierte en la única autoridad sobre la que los usuarios pueden lograr qué resultados frente a la API descendente. La API Original puede permitir intencionadamente (o no) a un usuario realizar una tarea que el usuario no puede realizar de otro modo. Por ejemplo, un usuario puede cambiar los detalles de otro usuario o leer y actualizar documentos a los que el usuario no tiene permiso de acceso. La validación incorrecta puede provocar problemas de seguridad graves.

Para mejorar la seguridad, la API original adquiere un token de acceso de permiso delegado para proporcionarlo a la API de bajada cuando la API original realiza la llamada. Veamos cómo funciona esto.

1. La aplicación cliente adquiere el token de acceso para llamar a la API original. La aplicación cliente adquiere un token de acceso de permiso delegado a la API original. El token de acceso de permiso delegado permite que la aplicación se ejecute en nombre del usuario para llamar a la API original que requiere autorización.
2. La aplicación cliente proporciona el token de acceso a la API original. La aplicación cliente proporciona el token de acceso a la API original. La API original valida e inspecciona completamente el token de acceso para determinar la identidad del usuario de la aplicación cliente.
3. La API original realiza la validación y aplicación de tokens. Una vez que la aplicación cliente proporciona el token de acceso a la API original, la API original realiza la validación y la aplicación del token. Si todo es bueno, la API continúa y ofrece la solicitud de la aplicación cliente.
4. La API original no puede usar el token de acceso para llamar a la API de bajada. La API original quiere llamar a una API de nivel inferior. Pero la API original no puede usar el token de acceso para llamar a la API de bajada.
5. La API original se remonta al identificador de Microsoft Entra. La API original debe volver al identificador de Microsoft Entra. Necesita un token de acceso para llamar a la API de bajada en nombre del usuario. La API original proporciona el token que la API original recibió de la aplicación cliente y las credenciales de cliente de la API original.
6. Microsoft Entra ID realiza comprobaciones. Microsoft Entra ID comprueba si hay cosas como el consentimiento o el cumplimiento del acceso condicional. Es posible que tenga que volver al cliente que realiza la llamada y proporcionar un motivo para no poder obtener el token. Normalmente, se usa un proceso de desafío de notificaciones para volver a la aplicación que realiza la llamada y proporcionar información sobre el consentimiento que no se ha recibido (por ejemplo, debido a las directivas de acceso condicional). Si todo está bien, Microsoft Entra ID emite un token de acceso a la API original para llamar a la API de bajada en nombre del usuario.
7. La API original tiene contexto de usuario con flujo enBehalf-Of. El proceso de flujo enBehalf-Of (OBO) permite que una API siga teniendo el contexto de usuario a medida que llama a la API de nivel descendente.
8. Llamadas a la API original de bajada. Llame a la API de bajada. El token que recibe la API de bajada tiene la notificación de audiencia adecuada (aud) que indica la API de bajada. El token incluye los ámbitos para el consentimiento concedido y la identidad de usuario de la aplicación original. La API de bajada puede implementar correctamente los permisos efectivos para asegurarse de que el usuario identificado tiene permiso para realizar la tarea solicitada. Quiere usar el flujo en nombre de para adquirir tokens para una API para llamar a otra API para asegurarse de que el contexto del usuario pasa a todas las API de bajada.

Mejor opción: la API original realiza el flujo con derechos delegados

La mejor opción es que la API original realice el flujo enBehalf-Of (OBO). Si la API de bajada recibe el token correcto, puede responder correctamente. Cuando una API actúa en nombre de un usuario y necesita llamar a otra API, la API original debe usar un flujo con derechos delegados para adquirir un token de acceso de permiso delegado y así poder llamar a la API de bajada en nombre del usuario. Las API nunca deben usar permisos de aplicación para llamar a otras API de bajada cuando la API actúa en nombre de un usuario.

Pasos siguientes

• Flujos de autenticación de la plataforma de identidad de Microsoft y escenarios de aplicaciones describe los flujos de autenticación y los escenarios de aplicación en los que se usan.
• En el artículo Protección de API se describen los procedimientos recomendados para proteger la API mediante su registro, la definición de permisos y del consentimiento, y la aplicación del acceso para lograr los objetivos de confianza cero.
• El artículo Ejemplo de una API protegida por el marco de consentimiento de identidades de Microsoft le ayuda a diseñar estrategias de permisos de aplicación con privilegios mínimos para ofrecer la mejor experiencia del usuario.
• Personalizar tokens describe la información que puede recibir en tokens de Microsoft Entra. Se explica cómo personalizar tokens para mejorar la flexibilidad y el control, al tiempo que aumenta la seguridad de confianza cero de la aplicación con privilegios mínimos.
• En el módulo Protección de API personalizadas con Microsoft Identity de Microsoft Learn se explica cómo proteger una API web con la identidad de Microsoft y cómo llamar a esa API desde otra aplicación.
• Procedimientos recomendados de seguridad para las propiedades de la aplicación describe el URI de redirección, los tokens de acceso, los certificados y los secretos, el URI de identificador de aplicación y la propiedad de la aplicación.
• En el artículo Bibliotecas de autenticación de la Plataforma de identidad de Microsoft se muestra la compatibilidad de la biblioteca de autenticación de Microsoft con varios tipos de aplicación.