Autenticar 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 identificación, si un actor malintencionado infringe o compromete tu aplicación, no hay nombres de usuario ni contraseñas correspondientes en tu aplicación.

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

1. Declaraciones de encabezado. Las declaraciones de encabezado presentes en los tokens de identidad incluyen typ (declaració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 declaración con el iss (nombre del emisor) que vaya a la aplicación que se emitió el token (la aud, o declaración de audiencia).
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": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
}.
.[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 un claim de audiencia (aud) que coincida con el ID de cliente de su aplicación, el usuario identificado en el token se ha autenticado en su 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 cuyo "claim" 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 las reclamaciones son importantes en la autenticación de usuario:

• Un JSON Web Token es válido hasta que expire. La afirmación exp (expiración) te 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 al usuario como autenticado antes del tiempo especificado en la aseveración nbf (no antes de la hora indicada). 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 (reclamo del sujeto) es un identificador único para un usuario de aplicación. El mismo usuario tiene una declaració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 el claim de sujeto. Dado que no expone la identidad de Microsoft Entra del usuario, es la forma más privada de asociar datos a un usuario. La reclamación sub es inmutable.
• Si desea compartir información entre varias aplicaciones, use la combinación de declaraciones de tenant (tid) y 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 reclamaciones sub, oid y tid permanecen inmutables. A pesar de que cualquier información sobre el usuario pueda cambiar, podrá seguir relacionando sus datos para identificar al usuario basándose en el asunto o en las reclamaciones 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.

Su aplicación recibirá un token de ID después de que el usuario haya completado 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, se incluye una declaració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 declaración exp desempeña un papel crucial para mantener a un usuario verificado explícitamente activo en la aplicación con el privilegio correcto y durante el 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. Elementos en la superficie web (como el estado de sesión y las cookies) después de la autenticación exitosa impulsan el SSO.

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 forma de nube y 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 una galleta. Debajo de la cookie, hay un subtítulo que dice "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 de la caja, hay otra caja. 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 (SSO) del navegador, específicamente con Microsoft Edge. Cuando el usuario inició sesión en Windows, los ajustes 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 navegador) permiten que ambos navegadores compartan el estado de SSO (inicio de sesión único) 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. Líneas con una flecha en cada extremo conectan cada uno de los cuatro cuadros con la forma de nube.

Enfoque de agente de autenticación

Un patrón común es que cada aplicación nativa tenga su propio WebView incrustado, lo que impide su participación en el inicio de sesión único (SSO). 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. Líneas con flechas en cada extremo conectan cada uno de los cuatro cuadros con la forma rectangular.

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 broker 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 intermediario 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: Valida un token de acceso describe cómo, cuando tiene un token de acceso de Microsoft Entra, verifica que determinados campos coinciden con el registro.
• Aumente la resistencia de las aplicaciones de autenticación y autorización que desarrolle. La serie aborda las aplicaciones que usan la plataforma de identidad de Microsoft y Microsoft Entra ID. Orientaciones 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 en segundo plano que funcionan por sí mismas. 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 reclamaciones 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 estos roles.
• Crear aplicaciones que protejan la identidad a través de permisos y consentimiento proporciona una visión general sobre los permisos y las mejores prácticas de acceso.