Compartir a través de

Guía para desarrolladores para el acceso condicional de Microsoft Entra

  • Artículo

La característica Acceso condicional de Microsoft Entra ID ofrece una de las distintas maneras que puede usar para proteger la aplicación y un servicio. El acceso condicional permite que los desarrolladores y clientes empresariales protejan los servicios de diversas formas, entre las que se incluyen las siguientes:

  • Autenticación multifactor
  • Autorización para que solo los dispositivos inscritos en Intune accedan a servicios específicos
  • Restricción de ubicaciones de usuario e intervalos IP

Para obtener más información sobre las funcionalidades completas del acceso condicional, consulte el artículo ¿Qué es el acceso condicional?

Para desarrolladores que compilan aplicaciones para Microsoft Entra ID, este artículo muestra cómo se puede usar el acceso condicional y también proporciona información sobre el impacto de acceder a los recursos sobre los que no se tiene control, y que pueden tener directivas de acceso condicional aplicadas. Este artículo explora además las implicaciones del acceso condicional en el flujo en el nombre de otra persona, aplicaciones web, el acceso a Microsoft Graph y las llamadas a las API.

Se da por hecho que tiene conocimientos sobre apps de inquilino único y multiinquilino, además de sobre los patrones comunes de autenticación.

Nota:

El uso de esta característica requiere una licencia Microsoft Entra ID P1. Para obtener la licencia correcta para sus requisitos, consulte Comparación de las características con disponibilidad general de las ediciones Gratis, Básico y Premium. Los clientes con licencias de Microsoft 365 Empresa también tienen acceso a características de acceso condicional.

¿Cómo el acceso condicional afecta a una aplicación?

Tipos de aplicación afectados

En los casos más comunes, el acceso condicional no cambia el comportamiento de una app ni requiere cambios por parte del desarrollador. Solo en ciertos casos en los que una aplicación solicita un token de manera indirecta o silenciosa para un servicio, se requieren cambios en el código de la aplicación para controlar los desafíos del acceso condicional. Puede ser tan sencillo como realizar una solicitud de inicio de sesión interactiva.

En concreto, en los escenarios siguientes:

  • Aplicaciones que realizan el flujo "en nombre de"
  • Aplicaciones que acceden a varios servicios o recursos
  • Aplicaciones de una sola página que usan MSAL.js
  • Aplicaciones web que llaman a un recurso

Las directivas de acceso condicional se pueden aplicar a la aplicación, pero también se pueden aplicar a una API web a la que accede la aplicación. Para más información sobre cómo configurar una directiva de acceso condicional, consulte Inicio rápido: Requerir MFA para aplicaciones específicas con acceso condicional a Microsoft Entra.

Según el escenario, un cliente empresarial puede aplicar y quitar directivas de acceso condicional en cualquier momento. Para que la aplicación siga funcionando cuando se aplica una nueva directiva, implemente el control de desafíos. En los ejemplos siguientes se ilustra el control de desafíos.

Ejemplos de acceso condicional

En algunos escenarios se requieren cambios en el código para controlar el acceso condicional, mientras que en otros se trabaja tal cual. Estos son algunos escenarios en los que se usa el acceso condicional para realizar la autenticación multifactor, lo que da una idea de la diferencia.

  • Se crea una aplicación iOS de inquilino único y se aplica una directiva de acceso condicional. La aplicación inicia la sesión de un usuario y no solicita acceso a una API. Cuando se inicia sesión, la directiva se invoca automáticamente y es necesario realizar la autenticación multifactor (MFA).
  • Está creando una app nativa que utiliza un servicio de nivel intermedio para tener acceso a una API de bajada. Un cliente empresarial de la empresa que usa esta aplicación aplica una directiva a la API de nivel inferior. Cuando un usuario final inicia sesión, la aplicación nativa solicita acceso al nivel intermedio y envía el token. El nivel intermedio realiza el flujo "en nombre de" para solicitar acceso a la API de nivel inferior. En este punto, se presenta un "desafío" de notificaciones al nivel intermedio. El nivel intermedio envía el desafío de vuelta a la aplicación nativa, la que necesita cumplir con la directiva de acceso condicional.

Microsoft Graph

Microsoft Graph tiene consideraciones especiales a la hora de crear aplicaciones en entornos de acceso condicional. Generalmente, la mecánica del acceso condicional se comporta de la misma manera, pero las directivas que los usuarios ven se basarán en los datos subyacentes que la aplicación está solicitando del gráfico.

Específicamente, todos los ámbitos de Microsoft Graph representan un conjunto de datos que puede tener directivas aplicadas individualmente. Dado que a las directivas de acceso condicional se les asignan conjuntos de datos específicos, Microsoft Entra ID aplica las directivas de acceso condicional basándose en los datos subyacentes a Graph, en lugar de en el propio Graph.

Por ejemplo, si una aplicación solicita los siguientes ámbitos de Microsoft Graph,

scopes="ChannelMessages.Read.All Mail.Read"

Una aplicación puede esperar que sus usuarios cumplan con todas las directivas establecidas en Teams y Exchange. Algunos ámbitos pueden asignarse a varios conjuntos de datos si se concede acceso.

Cumplimiento con una directiva de acceso condicional

En el caso de varias topologías de aplicaciones distintas, se evalúa una directiva de acceso condicional cuando se establece la sesión. Si bien una directiva de acceso condicional opera en la granularidad de aplicaciones y servicios, el punto en que se invoca depende en gran medida del escenario que intenta lograr.

Cuando la aplicación intenta acceder a un servicio con una directiva de acceso condicional, podría encontrar un desafío de acceso condicional. Este desafío se codifica en el parámetro claims, que se incluye en una respuesta de Microsoft Entra ID. Este es un ejemplo de este parámetro de desafío:

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Los desarrolladores pueden tomar este desafío y anexarlo a una solicitud nueva a Microsoft Entra ID. Cuando se pasa este estado, se solicita al usuario final que realice cualquier acción necesaria para cumplir con la directiva de acceso condicional. En los escenarios siguientes, se explican los detalles específicos del error y cómo extraer el parámetro.

Escenarios

Requisitos previos

El acceso condicional de Microsoft Entra es una característica incluida en Microsoft Entra ID P1 o P2. Los clientes con licencias de Microsoft 365 Empresa también tienen acceso a características de acceso condicional.

Consideraciones para escenarios específicos

La información siguiente solo se aplica en estos escenarios de acceso condicional:

  • Aplicaciones que realizan el flujo "en nombre de"
  • Aplicaciones que acceden a varios servicios o recursos
  • Aplicaciones de una sola página que usan MSAL.js

Las siguientes secciones describen escenarios comunes que son más complejos. El principio operativo central es que las directivas de acceso condicional se evalúan en el momento en que se solicita el token para el servicio que tiene aplicada una directiva de acceso condicional.

Escenario: Aplicación que realiza el flujo "en nombre de"

En este escenario, analizaremos un caso en el que una aplicación nativa llama a una API o servicio web. A su vez, este servicio realiza el flujo "en nombre de" para llamar a un servicio de bajada. En este caso, se aplica la directiva de acceso condicional al servicio de bajada (API web 2) y se usa una aplicación nativa en lugar de una aplicación demonio/servidor.

App performing the on-behalf-of flow diagram

La solicitud de token inicial para API web 1 no solicita al usuario final que realice la autenticación multifactor, porque API web 1 no siempre puede llegar a la API de bajada. Cuando API web 1 intenta solicitar un token en nombre del usuario para API web 2, la solicitud genera un error porque no se inició sesión con la autenticación multifactor.

Microsoft Entra ID devuelve una respuesta HTTP con algunos datos interesantes:

Nota:

En esta instancia se trata de la descripción de un error de autenticación multifactor, sino que es un intervalo amplio de interaction_required posiblemente perteneciente al acceso condicional.

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

En Web API 1, se captura el error error=interaction_required y el desafío claims se envía de vuelta a la aplicación de escritorio. En ese momento, la aplicación de escritorio puede realizar una llamada acquireToken() nueva y anexa el desafío claims como un parámetro de cadena de solicitud adicional. Esta solicitud nueva requiere que el usuario realice la autenticación multifactor y después envíe el token nuevo de vuelta a la API web 1 y complete el flujo con derechos delegados.

Para probar el escenario, consulte el ejemplo de código .NET. Muestra cómo pasar el desafío de notificaciones de vuelta desde API web 1 a la aplicación nativa y construye una solicitud nueva dentro de la aplicación cliente.

Escenario: Aplicación que accede a varios servicios

En este escenario se describe un caso en el que una aplicación web accede a dos servicios, uno de los cuales tiene asignada una directiva de acceso condicional. En función de la lógica de la aplicación, es posible que exista una ruta de acceso en la que la aplicación no requiera acceso a ambos servicios web. En este escenario, el orden en que se solicita un token representa un papel importante en la experiencia del usuario final.

Vamos a suponer que tenemos un servicio web A y B y que el servicio web B tiene aplicada la directiva de acceso condicional. Si bien la solicitud de autenticación interactiva inicial requiere consentimiento para ambos servicios, la directiva de acceso condicional no se requiere en todos los casos. Si la aplicación solicita un token para el servicio web B, se invoca la directiva y las solicitudes subsiguientes del servicio web A también se realizan correctamente, como se indica a continuación.

App accessing multiple-services flow diagram

De manera alternativa, si la aplicación inicialmente solicita un token para el servicio web A, el usuario final no invoca la directiva de acceso condicional. Esto permite que el desarrollador de la aplicación controle la experiencia del usuario final y no obligue a que la directiva de acceso condicional se invoque en todos los casos. La parte complicada aparece si la app solicita después un token para el servicio web B. En este punto, el usuario final tiene que cumplir con la directiva de acceso condicional. Si la aplicación intenta acquireToken, puede generar el error siguiente (que se ilustra en el diagrama a continuación):

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

App accessing multiple services requesting a new token

Si la aplicación usa la biblioteca MSAL, la adquisición de un token siempre se reintenta de forma interactiva si se genera un error. Cuando se produce esta solicitud interactiva, el usuario final tiene la oportunidad de cumplir con el acceso condicional. Esto se aplica a menos que la solicitud sea AcquireTokenSilentAsync o PromptBehavior.Never, en cuyo caso la aplicación debe realizar una solicitud AcquireToken interactiva para dar al usuario final la oportunidad de cumplir con la directiva.

Escenario: Aplicación de una sola página (SPA) que usa MSAL.js

En este escenario, se describe un caso en el que se tiene una aplicación de página única (SPA) que llama a una API web protegida por acceso condicional mediante MSAL.js. Se trata de una arquitectura simple, pero tiene algunos matices que se deben considerar cuando se desarrollen aplicaciones alrededor del acceso condicional.

En MSAL.js, existen algunas funciones que obtienen tokens: acquireTokenSilent(), acquireTokenPopup() yacquireTokenRedirect().

  • A continuación, acquireTokenSilent() se puede usar para obtener silenciosamente un token de acceso, lo que significa que no muestra la interfaz de usuario en ninguna circunstancia.
  • Tanto acquireTokenPopup() como acquireTokenRedirect() se usan para solicitar de manera interactiva un token para un recurso, lo que significa que siempre muestra la UI de inicio de sesión.

Cuando una aplicación necesita un token de acceso para llamar a una API web, intenta un acquireTokenSilent(). Si el token expira o es necesario cumplir con una directiva de acceso condicional, la función acquireToken genera un error y la aplicación usa acquireTokenPopup() o acquireTokenRedirect().

Single-page app using MSAL flow diagram

Veamos un ejemplo con el escenario de acceso condicional. El usuario final acaba de llegar al sitio y no tiene una sesión. Se realiza una llamada loginPopup() y se obtiene un token de identificador sin autenticación multifactor. Luego, el usuario presiona un botón que requiere que la aplicación solicite datos de una API web. La app intenta realizar una llamada acquireTokenSilent() pero se produce un error, ya que el usuario todavía no realizó la autenticación multifactor y debe cumplir con la directiva de acceso condicional.

Microsoft Entra ID devuelve la siguiente respuesta HTTP:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.

La aplicación debe capturar error=interaction_required. Luego, la aplicación puede usar acquireTokenPopup() o acquireTokenRedirect() en el mismo recurso. Se obliga al usuario a realizar la autenticación multifactor. Una vez que se completa la autenticación multifactor, la app recibe un nuevo token de acceso para el recurso solicitado.

Para probar este escenario, consulte nuestro código de ejemplo aplicación de página única de React que llama a la API web de Node.js mediante el flujo con derechos delegados. Este ejemplo de código usa la directiva de acceso condicional y la API web que registró anteriormente con un SPA de React para mostrar el escenario. Muestra cómo controlar de forma adecuada el desafío de notificaciones y obtener un token de acceso que se puede usar para la API web.

Consulte también