Compartir por

Administración de tokens para Zero Trust

En el desarrollo de aplicaciones de Confianza cero, es importante definir específicamente la intención de la aplicación y sus requisitos de acceso a los recursos. La aplicación debe solicitar solo el acceso que requiere para funcionar según lo previsto. Este artículo le ayuda, como desarrollador, a crear seguridad en las aplicaciones con tokens de identificador, tokens de acceso y tokens de seguridad que la aplicación puede recibir de la plataforma de identidad de Microsoft.

Asegúrese de que la aplicación cumple el principio de confianza cero de privilegios mínimos y evita el uso de maneras que pongan en peligro su intención. Limite el acceso de los usuarios con los modelos Just-In-Time y Just-Enough-Access (JIT/JEA), políticas adaptativas basadas en el riesgo y protección de datos. Separe las secciones confidenciales y eficaces de la aplicación. Proporcione solo acceso de usuario autorizado a estas áreas. Limite los usuarios que pueden usar la aplicación y las funcionalidades que tienen en la aplicación.

Cree privilegios mínimos en la forma en que la aplicación administra los tokens de identificador que recibe de la plataforma de identidad de Microsoft. La información de los tokens de identificador permite comprobar que un usuario es quien dice ser. El usuario o su organización pueden especificar condiciones de autenticación como MFA, dispositivos administrados y ubicaciones correctas.

Facilitar a los clientes la administración de autorizaciones en la aplicación. Reduzca la sobrecarga de creación y configuración del usuario y los procesos manuales. El aprovisionamiento automático de usuarios permite a los administradores de TI automatizar la creación, el mantenimiento y la eliminación de identidades de usuario en almacenes de identidades de destino. Los clientes pueden basar la automatización en cambios de usuarios y grupos mediante el aprovisionamiento de aplicaciones o el aprovisionamiento controlado por RR. HH en Microsoft Entra ID.

Uso de declaraciones de token en las aplicaciones

Utilice declaraciones en tokens de identificación para la experiencia del usuario dentro de la aplicación como claves en una base de datos. Proporcione acceso a la aplicación cliente. El token de identificador es la extensión principal que OpenID Connect (OIDC) realiza en OAuth 2.0. La aplicación puede recibir tokens de ID junto con o en lugar de tokens de acceso.

En el patrón estándar para la autorización de tokens de seguridad, un token de identificador emitido permite a la aplicación recibir información sobre el usuario. No use el token de identificador como proceso de autorización para acceder a los recursos. El servidor de autorización emite tokens de identificación que contienen reclamaciones con información de usuario, incluyendo lo siguiente.

  • La reclamación de audiencia (aud) es el identificador de cliente de la aplicación. Acepta solo tokens para el ID de cliente de la API.
  • La tid afirmación es el identificador del inquilino que emitió el token. La oid reclamación es un valor inmutable que identifica de forma única al usuario. Use la combinación única de las tid declaraciones y oid como una clave cuando necesite asociar datos al usuario. Use estos valores de declaración para asociar los datos al identificador del usuario en Microsoft Entra ID.
  • La sub reclamación es un valor inmutable que identifica de manera única al usuario. La reclamación del asunto también es única para la aplicación. Si usa el sub reclamo para asociar datos al usuario, es imposible partir de tus datos y conectarlos con un usuario en Microsoft Entra ID.

Las aplicaciones pueden usar el openid ámbito para solicitar un token de identificador desde la plataforma de identidad de Microsoft. El estándar OIDC rige el openid ámbito junto con el formato y el contenido del token de identificador. OIDC especifica estos ámbitos:

  • Use el openid ámbito para iniciar sesión del usuario y agregar una sub declaración al token de identificador. Estos alcances proporcionan un identificador de usuario que es único para la aplicación y el usuario y llama al punto de acceso UserInfo.
  • El email ámbito agrega una email notificación que contiene la dirección de correo electrónico del usuario al token de identificación.
  • El profile ámbito agrega cláusulas con atributos de perfil básicos del usuario (nombre, nombre de usuario) al token de identificación.
  • El offline_access ámbito permite a la aplicación acceder a los datos de usuario incluso cuando el usuario no está presente.

La Biblioteca de autenticación de Microsoft (MSAL) siempre agrega los ámbitos openid, email y profile a cada solicitud de token. Como resultado, MSAL siempre devuelve un token de identificador y un token de acceso en cada llamada a AcquireTokenSilent o AcquireTokenInteractive. MSAL siempre solicita el offline_access ámbito. La plataforma de identidad de Microsoft siempre devuelve el offline_access alcance, incluso cuando la aplicación solicitante no especifica el offline_access alcance.

Microsoft usa el estándar OAuth2 para emitir tokens de acceso. El estándar OAuth2 indica que recibe un token, pero no especifica el formato del token o lo que debe estar en el token. Cuando la aplicación necesita acceder a un recurso que protege Microsoft Entra ID, debe usar un ámbito definido por el recurso.

Por ejemplo, Microsoft Graph define el User.Read ámbito que autoriza a la aplicación a acceder al perfil de usuario completo del usuario actual y el nombre del inquilino. Microsoft Graph define los permisos en toda la gama de funcionalidades disponibles en esa API.

Tras la autorización, la plataforma de identidad de Microsoft devuelve un token de acceso a la aplicación. Al llamar al recurso, la aplicación proporciona este token como parte del encabezado de autorización de la solicitud HTTP a la API.

Administración de duraciones de tokens

Las aplicaciones pueden crear una sesión para un usuario después de que la autenticación se complete correctamente con el identificador de Microsoft Entra. La administración de sesiones de usuario impulsa la frecuencia con la que un usuario necesita repetir la autenticación. Su rol para mantener un usuario comprobado explícitamente delante de la aplicación con el privilegio correcto y para la cantidad de tiempo adecuada es fundamental. La duración de la sesión debe basarse en la exp reclamación en el token de ID. La exp declaración es la hora en la que expira el token de ID y la hora después de la cual ya no se podrá utilizar el token para autenticar al usuario.

Respete siempre la duración del token tal como se proporciona en la respuesta del token cuando se trata de tokens de acceso o la exp declaración en el token de identificador. Las condiciones que rigen la duración del token pueden incluir la frecuencia de inicio de sesión de una empresa. La aplicación no puede configurar la duración del token. No se puede solicitar una duración del token.

En general, asegúrese de que los tokens sean válidos y no expirados. La reclamación de audiencia (aud) debe coincidir con el identificador de cliente. Asegúrese de que el token procede de un emisor de confianza. Si tiene una API multiinquilino, puede optar por filtrar para que solo los inquilinos específicos puedan llamar a la API. Asegúrese de hacer cumplir la duración del token. Compruebe los nbf (no antes) y los exp (expiración) reclamos para asegurarse de que la hora actual esté dentro de los valores de estos dos reclamos.

No aspire a duraciones de sesión excepcionalmente largas o cortas. Deje que la duración del token de identificador concedido impulse esta decisión. Mantener activas las sesiones de la aplicación más allá de la validez del token infringe las reglas, directivas y preocupaciones que llevaron a un administrador de TI a establecer una duración de validez de token para evitar el acceso no autorizado. Las sesiones cortas degradan la experiencia del usuario y no aumentan necesariamente la posición de seguridad. Los marcos populares, como ASP.NET, le permiten establecer tiempos de espera de sesión y cookies a partir de la hora de expiración del token de Id. de Microsoft Entra. Siga el tiempo de expiración del token del proveedor de identidades para asegurarse de que las sesiones del usuario nunca sean más largas que las directivas que dicta el proveedor de identidades.

Caché y actualización de tokens

Recuerde almacenar en caché los tokens correctamente. MSAL almacena automáticamente en caché los tokens, pero los tokens tienen duraciones. Utiliza tokens durante toda su vida útil y almacenarlos en caché adecuadamente. Si solicitas repetidamente el mismo token, el throttling hace que tu aplicación sea menos receptiva. Si tu aplicación abusa de la emisión de tokens, el tiempo para emitir nuevos tokens para su aplicación se alarga.

Las bibliotecas de MSAL administran los detalles del protocolo OAuth2, incluida la mecánica de la actualización de tokens. Si no usa MSAL, asegúrese de que la biblioteca que prefiera hace un uso eficaz de los tokens de actualización.

Cuando el cliente adquiere un token de acceso para acceder a un recurso protegido, recibe un token de actualización. Use el token de actualización para obtener nuevos pares de tokens de acceso y actualización después de que expire el token de acceso actual. Utiliza el token de actualización para adquirir tokens de acceso adicionales para recursos adicionales. Los tokens de actualización se enlazan a una combinación de usuario y cliente (no a un recurso o inquilino). Puede usar un token de actualización para obtener tokens de acceso en cualquier combinación de recursos y entidades donde la aplicación tenga permisos.

Gestionar problemas y fallos de token

La aplicación nunca debe intentar validar, descodificar, inspeccionar, interpretar o examinar el contenido de un token de acceso. Estas operaciones son estrictamente responsabilidad de la API de recursos. Si la aplicación intenta examinar el contenido de un token de acceso, es muy probable que la aplicación se interrumpe cuando la plataforma de identidad de Microsoft emite tokens cifrados.

Rara vez, se produce un error en una llamada para recuperar un token debido a problemas como la red, la infraestructura o la interrupción del servicio de autenticación. Aumente la resistencia de la experiencia de autenticación en la aplicación si se produce un error de adquisición de tokens siguiendo estos procedimientos recomendados:

  • Almacenar en caché local y proteger tokens con cifrado.
  • No pase artefactos de seguridad, como tokens, a través de canales no seguros.
  • Comprenda y actúe ante excepciones y respuestas de servicio del proveedor de identidad.

A menudo, los desarrolladores tienen preguntas sobre cómo inspeccionar tokens para depurar problemas como recibir un error 401 al llamar a un recurso. A medida que más tokens cifrados le impiden buscar dentro de un token de acceso, debe encontrar alternativas para buscar dentro de los tokens de acceso. Para la depuración, la respuesta del token que contiene el token de acceso proporciona la información que necesita.

En el código, compruebe si hay clases de error en lugar de casos de error individuales. Por ejemplo, controle la interacción del usuario necesaria en lugar de errores individuales cuando el sistema no concede permiso. Dado que podría pasar por alto esos casos individuales, es mejor comprobar si hay un clasificador como la interacción del usuario en lugar de investigar códigos de error individuales.

Es posible que tenga que recurrir a AcquireTokenInteractive y proporcionar las reclamaciones que la llamada AcquireTokenSilent requiere. Al hacerlo, se garantiza una administración eficaz de la solicitud interactiva.

Pasos siguientes

  • Last updated on