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 firmante (sub) o id. 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 confía en la aplicación que no es de confianza, la cual es simplemente una llamada procedente 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 ha verificado Microsoft Entra ID.
Cuando una API (se hace referencia a ella como API original) llama a otra, es fundamental que la API a la que llamamos (se hace referencia a ella como API de bajada) sigue el proceso de validación descrito anteriormente. 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. Por tanto, la API original se convertirá en la única autoridad para decidir qué usuarios pueden obtener determinados resultados en la API de bajada. La API original podría permitir de forma intencionada (o involuntaria) a un usuario realizar una tarea que no podría realizar de otro modo. Por ejemplo, un usuario podría cambiar los detalles de otro usuario o leer y actualizar documentos a los que no tiene permiso para acceder. 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.
La aplicación cliente adquiere el token de acceso para llamar a la API original
En el diagrama siguiente se muestra la aplicación cliente y la API original.
La aplicación cliente adquirió un token de acceso de permiso delegado (indicado por la forma del pentágono con la etiqueta "A") 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.
La aplicación cliente proporciona el token de acceso a la API original
La siguiente animación muestra la aplicación cliente que 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.
La API original valida y aplica el token
La siguiente animación muestra que, después de que la aplicación cliente proporciona el token de acceso a la API original, la API original valida y aplica el token. Si todo es bueno, la API continúa y ofrece la solicitud de la aplicación cliente.
La API original no puede usar el token de acceso para llamar a la API de bajada
La siguiente animación muestra que la API original ahora quiere llamar a una API de bajada. Pero la API original no puede usar el token de acceso para llamar a la API de bajada.
La API original vuelve a Microsoft Entra ID
En la siguiente animación, la API original debe volver a Microsoft Entra ID. Necesita un token de acceso para llamar a la API de bajada en nombre del usuario.
La siguiente animación muestra la API original proporcionando el token que recibió de la aplicación cliente y las credenciales de cliente de la API original.
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).
Microsoft Entra ID realiza comprobaciones
En la siguiente animación, Microsoft Entra ID realiza sus comprobaciones. 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.
La API original tiene contexto del usuario mediante un flujo con derechos delegados
En la siguiente animación se muestra el proceso flujo con derechos delegados (OBO) que permite que una API siga teniendo el contexto del usuario a medida que llama a la API de bajada.
La API original llama a la API de bajada
En la siguiente animación, llamamos 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
Esta última animación muestra que la mejor opción es que la API original realice el flujo con derechos delegados. 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. 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.
- En el artículo Procedimientos recomendados de seguridad para las propiedades de la aplicación en Microsoft Entra ID se describen el URI de redireccionamiento, los tokens de acceso (usados para flujos implícitos), los certificados y los secretos, el identificador URI de la 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.