Autenticación de usuarios para Confianza cero

Este artículo le ayuda, como desarrollador, a aprender los procedimientos recomendados para autenticar a los usuarios de aplicaciones en el desarrollo de aplicaciones de confianza cero. Mejore de forma continua la seguridad de las aplicaciones con los principios de confianza cero de privilegios mínimos y compruebe explícitamente.

Tokens de id. en la autenticación de usuario

Cuando necesite que un usuario se autentique en la aplicación, en lugar de recopilar un nombre de usuario y una contraseña, la aplicación puede solicitar un token de identidad (ID). La autenticación de los usuarios a través de la Plataforma de identidad de Microsoft evita riesgos de seguridad que surgen cuando la aplicación conserva las credenciales de usuario. Al solicitar tokens de id., si un actor incorrecto infringe o pone en peligro la aplicación, no hay nombres de usuario y contraseñas correspondientes en la aplicación.

El token de identidad de Plataforma de identidad de Microsoft forma parte del estándar OpenID Connect (OIDC) que especifica tokens de identidad como JSON Web Tokens (JWT). La cadena larga JWT consta de tres componentes:

1. Notificaciones de encabezado. Las notificaciones de encabezado presentes en los tokens de identidad incluyen typ (notificación de tipo), alg (algoritmo para firmar el token) y kid (huella digital de la clave pública para validar la firma del token).
2. Notificaciones de carga. La carga o el cuerpo (la parte central de un JSON Web Token) contiene una serie de pares de atributos de nombre. El estándar requiere que haya una notificación con el iss (nombre del emisor) que vaya a la aplicación que se emitió el token (la audnotificación de audiencia o ).
3. Firma. Microsoft Entra ID genera la firma de token que las aplicaciones pueden usar para validar que el token no está modificado y puede confiar en él.

En el siguiente ejemplo de un token de identidad se muestra información sobre el usuario y se confirma la autenticación para usar la aplicación.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "6cb04018-a3f5-46a7-b995-940c78f5aef3",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "00000000-0000-0000-66f3-3332eca7ea81",
  "tid": "3338040d-6c67-4c5b-b112-36a304b66dad",
}.
.[Signature]

Tokens de identidad en la administración de acceso

Para recibir el identificador de la aplicación (cliente), registre la aplicación con la Plataforma de identidad de Microsoft. Cuando reciba un token con una notificación de audiencia (aud) que coincida con el id. de cliente de la aplicación, el usuario identificado en el token autenticado en la aplicación. Los administradores de TI pueden permitir que todos los usuarios del inquilino usen la aplicación. Pueden permitir que un grupo del que el usuario sea miembro use la aplicación.

Si recibe un token cuya notificación de audiencia es diferente del id. de cliente de la aplicación, rechace inmediatamente el token. El usuario no está autenticado en la aplicación porque inició sesión en otra aplicación. Asegúrese siempre de que el usuario tenga permiso para usar la aplicación.

Estos detalles de notificaciones son importantes en la autenticación de usuario:

• Un JSON Web Token es válido hasta que expire. La notificación exp (expiración) indica cuándo expira el token. Si la hora actual es anterior a la hora de la notificación exp, el token es válido.
• No considere el usuario como autenticado antes de la hora especificada en la notificación nbf (no antes del tiempo). Las horas nbf y exp del token definen la vigencia válida del token. Cuando la hora de expiración sea inminente, asegúrese de obtener un nuevo token de identidad.
• sub (notificación del firmante) es un identificador único para un usuario de aplicación. El mismo usuario tiene una notificación sub diferente para otras aplicaciones. Si desea almacenar datos para asociarlos a un usuario y evitar que un atacante realice esa asociación, use la notificación del firmante. Dado que no expone la identidad de Microsoft Entra del usuario, es la forma más privada de asociar datos a un usuario. La notificación sub es inmutable.
• Si desea compartir información entre varias aplicaciones, use la combinación de notificaciones de identidad de inquilino (tid) y notificaciones de id. de objeto (oid) que son únicas para el usuario. El id. de inquilino combinado y el id. de objeto son inmutables.
• Independientemente de lo que suceda con la identidad de un individuo, las notificaciones sub, oid y tid permanecen inmutables. Aunque cambie cualquier dato sobre el usuario, podrá seguir extrayendo los datos de identificación del usuario en función del asunto o de las notificaciones combinadas tid y oid.

Autenticación con OIDC

Para demostrar la autenticación de usuario, echemos un vistazo a las aplicaciones que usan OIDC para autenticar a un usuario. Los mismos principios se aplican a las aplicaciones que usan el Lenguaje de Marcado para Confirmaciones de Seguridad (SAML) o WS-Federation.

Una aplicación autentica al usuario cuando la aplicación solicita un token de identidad desde la Plataforma de identidad de Microsoft. Las cargas de trabajo (aplicaciones que no tienen usuarios presentes, sino que se ejecutan como servicios, procesos en segundo plano, demonios) omiten este paso.

Siempre debe pedir este token en modo silencioso primero. Para adquirir de forma silenciosa un token en las bibliotecas de autenticación de Microsoft (MSAL), la aplicación puede empezar con el método AcquireTokenSilent. Si la aplicación se puede autenticar sin molestar al usuario, recibe el token de identidad solicitado.

Si la Plataforma de identidad de Microsoft no puede completar la solicitud sin interactuar con el usuario, la aplicación debe recurrir al método AcquireTokenInteractive de MSAL. Para adquirir un token de forma interactiva, realice la solicitud abriendo una superficie web en una dirección bajo el dominio https://login.microsoftonline.com.

Desde esta superficie web, el usuario tiene una conversación privada con la Plataforma de identidad de Microsoft. La aplicación no puede ver esta conversación de ninguna forma ni tiene ningún control sobre ella. La plataforma de identidad de Microsoft puede solicitar un identificador de usuario y una contraseña, autenticación multifactor (MFA), autenticación sin contraseña u otra interacción de autenticación configurada por el administrador de TI o el usuario.

La aplicación recibirá un token de id. después de que el usuario haya realizado los pasos de autenticación necesarios. Cuando la aplicación recibe el token, puede estar seguro de que la plataforma de identidad de Microsoft ha autenticado al usuario. Si la aplicación no recibe un token de id., la plataforma de identidad de Microsoft no autenticaba al usuario. No permita que los usuarios no autenticados continúen en áreas protegidas de la aplicación.

Es recomendable que las aplicaciones creen una sesión para un usuario después de recibir un token de identidad de Microsoft Entra ID. En el token de identidad que recibe una aplicación, una notificación de expiración (exp) con una marca de tiempo de Unix. Esta marca de tiempo especifica la hora de expiración a la que, o después de la que, la aplicación no debe aceptar el JWT para su procesamiento. Use este tiempo de expiración del token para impulsar la duración de las sesiones de usuario. La notificación exp desempeña un papel fundamental para mantener un usuario comprobado explícitamente delante de la aplicación con el privilegio correcto y durante el período de tiempo adecuado.

Compatibilidad con el inicio de sesión único

El inicio de sesión único (SSO) es un método de autenticación que permite a los usuarios iniciar sesión con un conjunto de credenciales en varios sistemas de software independientes. El inicio de sesión único permite a los desarrolladores de aplicaciones no requerir que un usuario inicie sesión en cada aplicación por separado y repetidamente. En el núcleo del inicio de sesión único, los desarrolladores garantizan que todas las aplicaciones del dispositivo del usuario compartan la superficie web que autentica al usuario. Artefactos en la superficie web (como el estado de sesión y las cookies) después de la autenticación correcta del inicio de sesión único.

Como se muestra en el siguiente diagrama, el caso de uso más sencillo de una superficie web compartida es una aplicación que se ejecuta en un explorador web (como Microsoft Edge, Google Chrome, Firefox, Safari). Las pestañas del navegador comparten el estado de SSO.

Título del diagrama: Navegador web: caso más sencillo. En el centro superior del diagrama, aparece una nube que contiene un icono de Microsoft Entra ID. Debajo de la nube hay un cuadro. Una línea con una flecha en cada extremo conecta la nube con el cuadro. En la etiqueta del cuadro se lee "Al mantener la sesión iniciada, se guardan las cookies de estado de SSO en las invocaciones". Dentro del cuadro, en el lado izquierdo, hay un icono que parece a una galleta. Debajo de la galleta, hay un subtítulo en el que se puede leer "Conversación privada con el usuario". Debajo del subtítulo hay un icono que representa al usuario. A la izquierda de estos tres componentes, dentro del cuadro, hay otro cuadro. En la etiqueta del cuadro interno se puede leer "Pestañas". Debajo de la etiqueta hay cuatro cuadros que representan ventanas del navegador en pestañas.

La Plataforma de identidad de Microsoft administra el estado de SSO en cualquier navegador específico, a no ser que el usuario tenga distintos navegadores abiertos en el mismo dispositivo. En Windows 10 y versiones posteriores, la plataforma de identidad de Microsoft admite de forma nativa el inicio de sesión único del explorador Microsoft Edge. Cuando el usuario inició sesión en Windows, los alojamientos en Google Chrome (a través de la extensión de cuentas de Windows 10) y en Mozilla Firefox v91+ (a través de una configuración del explorador) permiten que cada explorador comparta el estado de SSO de Windows.

Como se muestra en el siguiente diagrama, el caso de uso de la aplicación nativa es más complicado.

Título del diagrama: Aplicaciones nativas: navegadores incrustados, sin inicio de sesión único. En el centro superior del diagrama, aparece una nube que contiene un icono de Microsoft Entra ID. En la parte inferior del diagrama hay cuatro cuadros distribuidos de forma horizontal. En la esquina inferior derecha de cada cuadro hay un icono que representa a un usuario. Dentro de cada uno de los cuadros hay una representación de las ventanas del navegador, incluido un icono de galleta y un icono de globo terráqueo. Una línea con una flecha en cada extremo conecta la nube con cada uno de los cuadros.

Enfoque de agente de autenticación

Un patrón común es que cada aplicación nativa tenga su propia vista web incrustada, lo que impide que participe en el inicio de sesión único. Para abordar este escenario, Microsoft Entra ID usa un enfoque de agente de autenticación para aplicaciones nativas, como se muestra en el siguiente diagrama.

Título del diagrama: Enfoque de agente de autenticación. En el centro superior del diagrama, aparece una nube que contiene un icono de Microsoft Entra ID. Debajo de la nube hay un rectángulo con la etiqueta "Agente de autenticación". El rectángulo contiene un icono de galleta y un icono de globo terráqueo. Una línea con una flecha en cada extremo conecta la nube con el rectángulo. En la parte inferior del diagrama hay cuatro cuadros distribuidos de forma horizontal. En la esquina inferior derecha de cada cuadro hay un icono que representa a un usuario. Los iconos de cada cuadro representan ventanas del navegador. Una línea con una flecha en cada extremo conecta cada uno de los cuadros con el rectángulo.

Con un agente de autenticación implementado, las aplicaciones envían solicitudes de autenticación al agente en lugar de enviarlas directamente a la Plataforma de identidad de Microsoft. De este modo, el agente se convierte en la superficie compartida para toda la autenticación en el dispositivo.

Además de proporcionar una superficie compartida, el agente de autenticación proporciona otras ventajas. Al adoptar confianza cero, es posible que las empresas quieran que las aplicaciones solo se ejecuten desde dispositivos administrados por la empresa. Entre los ejemplos de administración de dispositivos de la empresa, se incluyen la administración completa de dispositivos móviles (MDM) y los escenarios en los que los usuarios traen sus propios dispositivos, los cuales participan en la administración de aplicaciones móviles (MAM).

Por diseño, los sistemas operativos subyacentes (SO) aíslan los navegadores. Los desarrolladores necesitan una conexión más estrecha con el sistema operativo para tener acceso completo a los detalles del dispositivo. En Windows, el agente de autenticación es el Administrador de cuentas web (WAM) de Windows. En otros dispositivos, el agente de autenticación es la aplicación Microsoft Authenticator (para dispositivos que ejecutan iOS o Android) o la aplicación Portal de empresa (para dispositivos que ejecutan Android). Las aplicaciones acceden al agente de autenticación con MSAL. En Windows, una aplicación puede acceder a WAM sin MSAL. Sin embargo, MSAL es la manera más sencilla de que las aplicaciones accedan al agente de autenticación (especialmente las aplicaciones que no son de la Plataforma universal de Windows).

Los agentes de autenticación trabajan junto con Microsoft Entra ID para usar tokens de actualización principal (PRT) que reducen la necesidad de que los usuarios se autentiquen varias veces. Los PRT pueden determinar si el usuario está en un dispositivo administrado. Microsoft Entra ID requiere agentes de autenticación, ya que presenta tokens de prueba de posesión, una opción más segura sobre los tokens de portador que son frecuentes actualmente.

Pasos siguientes

• Solución de problemas de tokens de acceso de Microsoft Entra: Validación de un token de acceso describe cómo, cuando tiene un token de acceso de Microsoft Entra, se comprueba que determinados campos coinciden con el registro.
• Aumente la resistencia de las aplicaciones de autenticación y autorización que desarrolle aplicaciones de serie que usan la plataforma de identidad de Microsoft y el Microsoft Entra ID. Hay instrucciones que van dirigidas tanto a las aplicaciones cliente y de servicio que funcionan en nombre de un usuario que ha iniciado sesión como a las aplicaciones de demonio que funcionan en su propio nombre. Contienen procedimientos recomendados para el uso de tokens, así como para la llamada a los recursos.
• Personalizar tokens describe la información que puede recibir en tokens de Microsoft Entra y cómo puede personalizar los tokens.
• Configurar notificaciones de grupo y roles de aplicación en tokens muestra cómo configurar las aplicaciones con definiciones de roles de aplicación y asignar grupos de seguridad a roles de aplicación.
• Compilación de aplicaciones que protegen la identidad a través de permisos y consentimiento proporcionan información general sobre los permisos y los procedimientos recomendados de acceso.