Compartir a través de

Administración de tokens para Confianza cero

  • Artículo

Al desarrollar aplicaciones con confianza cero, es importante definir específicamente la intención de la aplicación y sus requisitos de acceso a recursos. La aplicación debe solicitar solo el acceso que requiere para funcionar según lo previsto. Este artículo ayuda a los desarrolladores a crear seguridad en aplicaciones con tokens de identidad, tokens de acceso y tokens de seguridad que puede recibir su aplicación desde la Plataforma de identidad de Microsoft.

Asegúrese de que la aplicación cumple el principio de privilegios mínimos del enfoque de confianza cero y evita usarla de maneras que pongan en peligro su intención. Limite el acceso de los usuarios con los modelos Just-in-Time y Just-in-Time (JIT/JEA), directivas que se adaptan al nivel de riesgo y protección de datos. Separe las secciones más confidenciales y potentes de la aplicación y proporcione acceso autorizado a los usuarios 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 para la forma en que la aplicación administra los tokens de identidad que recibe de la Plataforma de identidad de Microsoft. La información de los tokens de identidad permite comprobar que un usuario es quien dice ser. El usuario o su organización pueden especificar condiciones de autenticación como proporcionar MFA, usar un dispositivo administrado y estar en la ubicación adecuada.

Facilite a los clientes la administración de autorizaciones en la aplicación. Reduzca la sobrecarga de aprovisionamiento de usuarios y la necesidad de 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 las automatizaciones en los cambios de usuarios y grupos con el aprovisionamiento de aplicaciones o el aprovisionamiento controlado por recursos humanos en Microsoft Entra ID.

Uso de notificaciones de token en las aplicaciones

Utilice notificaciones en tokens de identidad para la experiencia del usuario en la aplicación, como claves en una base de datos, y para proporcionar acceso a la aplicación cliente. El token de identidad es la extensión principal que OpenID Connect (OIDC) establece en OAuth 2.0. La aplicación puede recibir tokens de identidad junto a tokens de acceso o en sustitución de estos.

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

  • La notificación de audiencia (aud) es el id. de cliente de la aplicación. Acepte solo tokens con el id. de cliente de su API.
  • La notificación tid es el identificador del inquilino que emitió el token. La notificación oid es un valor inmutable que identifica de forma única al usuario. Use la combinación única de las notificaciones tid y oid como clave cuando necesite asociar datos al usuario. Puede usar estos valores de notificación para volver a conectar los datos al identificador del usuario en Microsoft Entra ID.
  • La notificación sub es un valor inmutable que identifica de forma única al usuario. La notificación de asunto también es única para la aplicación. Si usa la notificación sub para asociar datos al usuario, es imposible partir desde los datos y conectarlos con un usuario en Microsoft Entra ID.

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

  • Use el ámbito openid para iniciar sesión en el usuario y agregar una notificación sub al token de identidad. Estos ámbitos proporcionan un identificador de usuario que es único para la aplicación y el usuario, y llama al punto de conexión UserInfo.
  • El ámbito email agrega una notificación email que contiene la dirección de correo electrónico del usuario al token de identidad.
  • El ámbito profile agrega notificaciones con atributos de perfil básicos del usuario (nombre de usuario, nombre de usuario) al token de identificador.
  • El ámbito offline_access 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 identidad y un token de acceso en cada llamada a AcquireTokenSilent o AcquireTokenInteractive. MSAL siempre solicita el ámbito offline_access. La Plataforma de identidad de Microsoft siempre devuelve el ámbito offline_access incluso cuando la aplicación solicitante no especifica el ámbito offline_access.

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 incluir. 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 ámbito User.Read que autoriza a la aplicación a acceder al perfil de usuario completo del usuario actual y al nombre del inquilino. Microsoft Graph define los permisos en toda la variedad 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 a la API este token como parte del encabezado de autorización de la solicitud HTTP.

Administración de la duración de los tokens

Las aplicaciones pueden crear una sesión para un usuario después de que la autenticación se complete correctamente con Microsoft Entra ID. La administración de sesiones de usuario gestiona la frecuencia con la que un usuario necesita volver a autenticarse. Esta función desempeña un papel fundamental para que la aplicación pueda ver a un usuario que se ha comprobado explícitamente con el privilegio correcto y durante el período de tiempo adecuado. La duración de la sesión debe basarse en la notificación exp del token de identidad. La notificación exp es la hora en la que expira el token de identidad y la hora después de la cual ya no se podrá usar el token para autenticar al usuario.

Respete siempre la duración del token tal como se proporciona en la respuesta de los tokens de acceso o la notificación exp del token de identidad. Entre las condiciones que rigen la duración del token se incluye la frecuencia de inicio de sesión de una empresa. La aplicación no puede configurar la duración del token. Además, usted no puede solicitar una duración del token.

En general, los tokens deben ser válidos y no estar expirados. La notificación de audiencia (aud) debe coincidir con el id. 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 inquilinos específicos puedan llamar a la API. Asegúrese de aplicar la duración del token. Compruebe las notificaciones nbf (not before) y exp (expiration) para asegurarse de que la hora actual está dentro de esos dos valores de notificaciones.

No busque tener una duración de sesión excepcionalmente larga o corta. Deje que la duración del token de identidad concedida sea la que determine 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 del token para evitar el acceso no autorizado. Las sesiones cortas degradan la experiencia del usuario y no mejoran necesariamente la posición de seguridad. Los marcos populares, como ASP.NET, permiten establecer tiempos de espera de sesión y cookies a partir de la hora de expiración del token del identificador de Microsoft Entra ID. Después de la hora de expiración del token del proveedor de identidades, se garantiza que las sesiones del usuario nunca superarán la duración establecida en las directivas que dicta el proveedor de identidades.

Caché y tokens de actualización

Recuerde almacenar en caché los tokens. MSAL almacena automáticamente en caché los tokens, pero estos tienen duraciones. Use los tokens el tiempo especificado en sus duraciones y almacénelos en caché adecuadamente. Si solicita repetidamente el mismo token, la limitación hace que la aplicación tenga menos capacidad de respuesta. Si la aplicación abusa de la emisión de tokens, aumenta el tiempo necesario para emitir nuevos tokens a la aplicación.

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

Cuando su cliente adquiere un token de acceso para acceder a un recurso protegido, recibe también un token de actualización. Utilice el token de actualización para obtener nuevos pares de tokens de acceso/actualización cuando expire el token de acceso actual. Utilícelos también para adquirir tokens de acceso adicionales para otros recursos. Los tokens de actualización están enlazados a una combinación de usuario y cliente, pero no a un recurso ni un inquilino. Puede usar un token de actualización para adquirir tokens de acceso en cualquier combinación de recurso e inquilino en casos en los que su aplicación tenga los permisos correspondientes.

Administración de errores de token

La aplicación nunca debe intentar validar, descodificar, inspeccionar, interpretar ni 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 interrumpa cuando la Plataforma de identidad de Microsoft emita tokens cifrados.

En raras ocasiones, las llamadas para recuperar un token pueden no funcionar debido a errores como un fallo o una interrupción de la red, la infraestructura o el 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:

  • Almacene en la memoria caché local los tokens y protéjalos con cifrado.
  • No pase artefactos de seguridad como tokens por canales no seguros.
  • Conozca y actúe sobre excepciones y respuestas de servicio del proveedor de identidades.

A menudo, los desarrolladores tienen preguntas sobre cómo buscar dentro de tokens para depurar problemas como el error 401 que se produce al llamar al recurso. A medida que más tokens cifrados le impiden mirar dentro de un token de acceso, debe encontrar alternativas para consultar 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 puede pasar por alto esos casos individuales, es mejor comprobar si hay un clasificador como la interacción del usuario en lugar de profundizar en códigos de error individuales.

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

Pasos siguientes