Compartir vía

Aplicación cliente públicas y confidenciales

  • Artículo

La Biblioteca de autenticación de Microsoft (MSAL) define dos tipos de clientes: clientes públicos y clientes confidenciales. Un cliente es una entidad de software que tiene un identificador único asignado por un proveedor de identidades. Los tipos de cliente se distinguen por su capacidad de autenticarse de forma segura con el servidor de autorización y contener información confidencial, que demuestra la identidad para que no se pueda acceder a un usuario o conocerlo dentro del ámbito de su acceso.

Aplicaciones cliente públicas Aplicaciones cliente confidenciales
Aplicación de escritorio Aplicación de escritorio Aplicación web Aplicación web
API sin explorador API sin explorador API Web API web
Aplicación móvil Aplicación móvil Demonio o servicio Servicio o demonio

Cliente público y autorización de cliente confidencial

Al examinar la naturaleza pública o confidencial de un cliente determinado, estamos evaluando la capacidad de ese cliente para demostrar su identidad en el servidor de autorización. Esto es importante porque el servidor de autorización debe poder confiar en la identidad del cliente para emitir los token de acceso.

  • Las aplicaciones cliente públicas se ejecutan en dispositivos, como dispositivo de escritorio, API sin explorador, aplicaciones móviles o de explorador del lado cliente. No pueden ser de confianza para mantener los secretos de aplicación de forma segura, ya que solo pueden acceder a las API web en nombre del usuario. Cada vez que el código de bytes compilado o de origen de una aplicación determinada se transmite en cualquier lugar en el que se pueda leer, desensamblar o inspeccionarlo por partes que no son de confianza, es un cliente público. Como también admiten flujos de cliente públicos y no pueden contener secretos en tiempo de configuración, no pueden tener secretos de cliente.

  • Las aplicaciones cliente confidenciales se ejecutan en servidores, como aplicaciones web, aplicaciones de API web o aplicaciones de servicio o demonio. Los usuarios o atacantes las consideran de difícil acceso y, por lo tanto, pueden contener adecuadamente secretos en tiempo de configuración para afirmar la prueba de su identidad. El Id. de cliente se expone a través del explorador web, pero el secreto solo se transmite en el canal posterior y nunca se expone directamente.

¿Cuándo se debe habilitar la opción para permitir un flujo de cliente público en el registro de la aplicación?

Después de determinar el tipo de aplicación cliente que estás compilando, puedes decidir si habilitar el flujo de cliente público en el registro de la aplicación. De forma predeterminada, permitir el flujo de cliente público en el registro de la aplicación debe deshabilitarse a menos que tú o el desarrollador estéis compilando una aplicación cliente pública y estéis usando el siguiente protocolo de autorización o características de OAuth:

Protocolo de autorización/característica de OAuth Tipo de aplicación cliente pública Ejemplos y notas
Autenticación nativa La aplicación Id. externa de Microsoft Entra que requiere una personalización completa de la interfaz de usuario, incluidos los elementos de diseño y la colocación del logotipo y el diseño, lo que garantiza un aspecto coherente y de marca. Nota: La autenticación nativa solo está disponible para los registros de aplicaciones en inquilinos de Id. externa de Microsoft Entra. Más información aquí.
Flujo de código de dispositivo Aplicaciones que se ejecutan en dispositivos con restricciones de entrada, como un televisor inteligente, un dispositivo IoT o una impresora
Flujo de credencial de contraseña del propietario del recurso Las aplicaciones que controlan las contraseñas que los usuarios escriben directamente, en lugar de redirigir a los usuarios al sitio web de inicio de sesión hospedado de Entra y permitir que Entra controle la contraseña de usuario de forma segura. Microsoft recomienda no utilizar el flujo ROPC. En la mayoría de los casos, existen y se recomiendan alternativas más seguras, como el flujo de código de autorización.
Flujo de autenticación integrada de Windows Aplicaciones de escritorio o móviles que se ejecutan en Windows o en una máquina conectada a un dominio de Windows (unido a Microsoft Entra ID o Microsoft Entra) mediante el flujo de autenticación integrada de Windows en lugar del administrador de cuentas web Una aplicación de escritorio o móvil que debería iniciar sesión automáticamente después de que el usuario haya iniciado sesión en el sistema Windows PC con una credencial de Microsoft Entra

Secretos y su importancia para demostrar la identidad

A continuación se muestran algunos ejemplos de cómo un cliente puede demostrar su identidad en el servidor de autorización:

  • Identidades administradas para recursos de Azure: Para escenarios de autenticación solo para aplicaciones, los desarrolladores de aplicaciones y servicios basados en Azure tienen la opción de descargar la administración, rotación y protección de secretos en la propia plataforma. Con las identidades administradas, las identidades se proporcionan y eliminan con recursos de Azure y nadie, incluido el administrador global, puede acceder a las credenciales subyacentes. Mediante el uso de identidades administradas, puede evitar el riesgo de pérdida de secretos y permitir que el proveedor controle la seguridad por usted.
  • Id. de cliente y secreto: En este patrón, el servidor de autorización genera un par de valores al registrar un cliente. El id. de cliente es un valor público que identifica la aplicación, mientras que el secreto de cliente es un valor confidencial que se usa para demostrar la identidad de la aplicación.
  • Demostrar la posesión de un certificado: Infraestructura de clave pública (PKI), que incluye estándares como X.509, es la tecnología fundamental que permite una comunicación segura a través de Internet y forma la red troncal de la privacidad de Internet. PKI se usa para emitir certificados digitales que comprueban la identidad de las partes implicadas en la comunicación en línea y es la tecnología subyacente que impulsa protocolos como HTTPS, que se usa ampliamente para proteger el tráfico web. Del mismo modo, los certificados se pueden usar para proteger la comunicación entre servicios (S2S) en Azure habilitando la autenticación mutua entre los servicios. Esto implica que cada servicio presente un certificado al otro como medio para demostrar su identidad.
  • Presentación de una aserción firmada: Usada en la federación de identidades de carga de trabajo, las aserciones firmadas permiten el intercambio de un token de proveedor de identidades de terceros de confianza con la plataforma de identidad de Microsoft para obtener tokens de acceso para llamar a los recursos protegidos por Microsoft Entra ID. La federación de identidades de carga de trabajo se puede usar para habilitar varios escenarios de federación, como Azure Kubernetes Service, Amazon Web Services EKS, Acciones de GitHub, etc.

¿Cuándo es importante probar la identidad del cliente?

Demostrar la identidad de cliente es importante cuando es necesario comprobar tanto la autenticidad como la autorización de una aplicación cliente antes de conceder acceso a datos confidenciales o recursos. Estos son algunos ejemplos:

  • Controlar el acceso a la API: Si tiene una API que se mide (por ejemplo, para la facturación) o expone datos o recursos confidenciales, comprobará la identidad del cliente antes de conceder acceso. Por ejemplo, esto es importante al garantizar que solo las aplicaciones autorizadas tengan acceso a la API y que el cliente correcto se factura por su uso de API medido.
  • Proteger a los usuarios de la suplantación de aplicaciones: Si tiene una aplicación orientada al usuario implementada por el servicio (como una aplicación web controlada por back-end) que accede a datos o servicios confidenciales, usar secretos de cliente para proteger los recursos utilizados por esa aplicación puede impedir que los actores incorrectos suplantan a un cliente legítimo para filtrar datos o realizar accesos indebidos.
  • Comunicación S2S: Si tiene varios servicios back-end (por ejemplo, API de bajada) que necesitan comunicarse entre sí, puede comprobar la identidad de cada servicio para asegurarse de que están autorizados para acceder solo a los recursos necesarios para realizar su función.

En general, demostrar la identidad del cliente es importante cuando es necesario autenticar y autorizar a un cliente independientemente de un usuario o además de él.

Clientes confidenciales: Procedimientos recomendados para administrar secretos

Uso de las identidades administradas para simplificar la implementación y la seguridad: Las identidades administradas proporcionan una identidad administrada automáticamente en Microsoft Entra ID para que las aplicaciones la utilicen al conectarse a recursos que admiten la autenticación de Microsoft Entra ID. Las aplicaciones pueden usar identidades administradas para obtener tokens exclusivos de la aplicación Microsoft Entra ID sin tener que administrar credenciales. Esto puede quitar muchas de las complejidades asociadas a la administración de secretos, al tiempo que aumenta la seguridad y la resistencia. Si usa identidades administradas, la mayoría, si no todos los procedimientos recomendados siguientes ya se encargan de usted.

Uso del almacenamiento seguro: Almacena secretos de cliente en una ubicación segura, como Key Vault o un archivo de configuración cifrado. Evite almacenar secretos de cliente en texto no cifrado o como archivos protegidos en sistemas de control de versiones.

Limitar el acceso: Limite el acceso a los secretos del cliente únicamente al personal autorizado. Utilice el control de acceso basado en rol para restringir el acceso a secretos de cliente solo a aquellos que lo necesiten para realizar sus tareas operativas.

Rotar secretos de cliente: Rotación de secretos de cliente según sea necesario o programado, puede minimizar el riesgo de que se use un secreto en peligro para obtener acceso no autorizado. Cuando se aplica, el intervalo de tiempo durante el que se sugiere que una clave permanezca en uso se ve afectada por la intensidad del algoritmo criptográfico utilizado o el cumplimiento de estándares o prácticas de cumplimiento normativo.

Uso de secretos largos y cifrado seguro: Estrechamente relacionado con el punto anterior, el uso de algoritmos de cifrado seguros para los datos tanto en tránsito (en la conexión) como en reposo (en disco) ayuda a garantizar que los secretos de alta entropía siguen siendo poco probable que sean forzados por fuerza bruta. Los algoritmos como AES-128 (o superior) pueden ayudar a proteger los datos en reposo, mientras que RSA-2048 (o superior) puede ayudar a proteger eficazmente los datos en tránsito. Debido a la naturaleza en constante evolución de la ciberseguridad, siempre es recomendable consultar a los expertos en seguridad y revisar periódicamente la selección de algoritmos.

Evitar codificación rígida de secretos: No codifique los secretos de cliente en el código fuente. Evitar secretos en el código fuente puede minimizar el valor de que los actores incorrectos obtengan acceso al código fuente. También puede impedir que estos secretos se inserten accidentalmente en repositorios no seguros o que estén disponibles para los colaboradores del proyecto que podrían tener acceso al origen, pero no a los secretos.

Supervisar repositorios para secretos filtrados: Es un hecho lamentable que se producen comprobaciones incorrectas al tratar con código fuente. Los enlaces previos a la confirmación de Git son una manera sugerida de evitar las comprobaciones accidentales, pero no es un sustituto de la supervisión. La supervisión automatizada de repositorios puede identificar secretos filtrados y, con un plan implementado para rotar las credenciales en peligro, puede ayudar a reducir los incidentes de seguridad.

Supervisión de actividades sospechosas: Supervise registros y pistas de auditoría para actividades sospechosas relacionadas con secretos de cliente. Siempre que sea posible, use alertas automatizadas y procesos de respuesta para notificar al personal y definir contingencias para actividades inusuales relacionadas con secretos de cliente.

Diseño de las aplicaciones con la confidencialidad de cliente en mente: El modelo de seguridad solo es tan fuerte como el vínculo más débil de la cadena. No reenviar credenciales de seguridad ni tokens de clientes confidenciales a clientes públicos, ya que esto podría mover datos secretos de cliente a un cliente público, lo que permite la suplantación del cliente confidencial.

Uso de las bibliotecas y SDK actualizados de orígenes de confianza: La plataforma de identidad de Microsoft proporciona varios SDK de cliente y servidor y middleware diseñados para aumentar la productividad y mantener las aplicaciones seguras. Las bibliotecas como Microsoft.Identity.Web simplifican la adición de autenticación y autorización a aplicaciones web y API en la plataforma de identidad de Microsoft. Mantener actualizadas las dependencias ayuda a garantizar que las aplicaciones y los servicios se beneficien de las últimas innovaciones y actualizaciones de seguridad.

Comparación de los tipos de cliente y sus funcionalidades

A continuación se muestran algunas similitudes y diferencias entre las aplicaciones cliente públicas y las confidenciales:

  • Ambos tipos de aplicación mantienen una caché de tokens de usuario y pueden adquirir un token de forma silenciosa (cuando el token está presente en la memoria caché). Las aplicaciones cliente confidenciales también tienen una caché de tokens de aplicación para los tokens adquiridos por la propia aplicación.
  • Ambos tipos de aplicación pueden administrar cuentas de usuario y obtener una cuenta de la caché de tokens de usuario, obtener una cuenta de su identificador o quitar una cuenta.
  • En MSAL, las aplicaciones cliente públicas tienen cuatro maneras de adquirir un token a través de flujos de autenticación independientes. Las aplicaciones cliente confidenciales solo tienen tres maneras de adquirir un token y una manera de calcular la dirección URL del punto de conexión de autorización del proveedor de identidades. El Id. de cliente se pasa una vez en la construcción de la aplicación y no es necesario volver a pasarlo cuando la aplicación adquiere un token. Para obtener más información, consulte Adquisición de tokens.

Los clientes públicos son útiles para habilitar el acceso delegado de usuario a los recursos protegidos, pero no pueden demostrar su propia identidad de aplicación. Por otro lado, los clientes confidenciales pueden realizar la autenticación y autorización de usuarios y aplicaciones y deben crearse teniendo en cuenta la seguridad para asegurarse de que sus secretos no se compartan con clientes públicos u otros terceros.

En algunos casos, como la comunicación S2S, la infraestructura como las identidades administradas ayuda considerablemente a simplificar el desarrollo y la implementación de servicios y elimina gran parte de la complejidad asociada normalmente a la administración de secretos. Cuando no se pueden usar las identidades administradas, es importante tener directivas, medidas preventivas y contingencias para proteger secretos y responder a incidentes de seguridad relacionados con ellas.

Consulte también

Para más información sobre la configuración de la aplicación y la creación de instancias, vea lo siguiente: