Es probable que ya se esté enfrentando a esto. El personal inicia sesión en Microsoft 365, luego en una herramienta de reservas, luego en RR. HH., luego en una aplicación empresarial y, después, en la WiFi corporativa, a menudo con un método diferente para cada paso. Un grupo hotelero tiene un conjunto de sistemas en la sede central y otro en las instalaciones. Un hospital cuenta con aplicaciones clínicas, estaciones de trabajo compartidas y acceso inalámbrico segmentado. Un operador de retail tiene personal que se mueve entre tiendas, tabletas, TPV y cuadros de mando de back-office.
Esa mezcla genera fricción rápidamente. Los usuarios olvidan las contraseñas, los equipos de TI restablecen las cuentas y las credenciales WiFi compartidas permanecen activas mucho más tiempo de lo debido. El resultado no es solo una molestia. Es un menor control sobre quién puede acceder a qué, desde qué dispositivo y durante cuánto tiempo.
Ahí es donde el inicio de sesión único, o SSO, resulta de gran utilidad. Si está buscando qué es el inicio de sesión único, la respuesta corta es sencilla: permite que un usuario se autentique una vez y luego acceda a múltiples sistemas aprobados sin tener que volver a introducir sus credenciales una y otra vez. La respuesta más práctica es operativa. El SSO proporciona a TI una capa de identidad única para el acceso a las aplicaciones y, con el diseño adecuado, también puede dar soporte a la forma en que las personas y los dispositivos se unen a redes seguras.
El fin del caos de las contraseñas
La mayoría de los entornos empresariales no se volvieron complejos a propósito. Simplemente crecieron así. Una aplicación en la nube se convirtió en cinco. Una oficina pasó a ser múltiples centros. Una red inalámbrica para TI se ramificó en diferentes SSIDs para el personal, invitados, contratistas y dispositivos.
Así es como empieza la dispersión de contraseñas. Un empleado puede necesitar el correo electrónico, RR. HH., programación de turnos, acceso a archivos, cuadros de mando internos y acceso a la red, todo antes de poder realizar cualquier trabajo real. IBM describe el SSO como un esquema en el que los usuarios inician sesión una vez con un único conjunto de credenciales y acceden a múltiples aplicaciones durante la misma sesión, lo que es posible gracias a una relación de confianza entre los proveedores de servicios y un proveedor de identidad. La descripción general de IBM sobre el single sign-on se ajusta estrechamente a lo que las organizaciones del Reino Unido necesitaban a medida que se aceleraban la adopción de la nube y el trabajo en remoto.
El impacto de la dispersión de contraseñas en las operaciones
Cuando cada aplicación solicita su propio inicio de sesión, los usuarios empiezan a tomar atajos. Reutilizan contraseñas. Las guardan en los navegadores. Piden a sus compañeros la "contraseña de la WiFi del personal" porque es más rápido que esperar a TI.
Para un responsable de TI de una gran empresa, el control es la máxima prioridad. Los inicios de sesión independientes crean islas de acceso separadas, y esas islas son más difíciles de gobernar cuando las personas cambian de puesto, abandonan la empresa o trabajan en varias ubicaciones.
El caos de las contraseñas rara vez es un único gran fallo. Normalmente son un centenar de pequeñas decisiones de acceso que nadie puede gestionar de forma coherente.
Por qué el SSO cambia el panorama
El SSO reduce la cantidad de contraseñas que los usuarios deben gestionar, lo que mejora la experiencia de inicio de sesión y ofrece una mayor seguridad cuando se combina con una política centralizada y MFA. También se adapta a la realidad de las organizaciones distribuidas donde el personal necesita un único inicio de sesión para el correo electrónico, recursos humanos, herramientas de reserva, POS, aplicaciones internas y servicios del sitio.
Esa misma lógica está dando forma ahora al acceso a la red. Si ya está avanzando hacia el acceso basado en la identidad para las aplicaciones, tiene sentido considerar el WiFi sin contraseña como parte del mismo enfoque de diseño, no como un problema independiente.
Comprender el concepto básico de SSO
El SSO desplaza la autenticación fuera de cada aplicación individual y la sitúa en un único sistema de identidad de confianza. El usuario inicia sesión una vez, se verifica esa identidad y los servicios conectados aceptan ese resultado en lugar de pedir otra contraseña.
Eso suena sencillo, pero el valor es arquitectónico. Está cambiando el lugar donde reside la confianza.
Las tres partes en cada flujo de SSO
Cada diseño de SSO cuenta con tres participantes, y cada uno tiene una función diferente:
- El usuario desea acceder a una aplicación, servicio o recurso de red.
- El Proveedor de Identidad o IdP verifica la identidad y aplica la política de inicio de sesión. Entre los ejemplos habituales en las organizaciones del Reino Unido se incluyen Microsoft Entra ID y Okta.
- El Proveedor de Servicios o SP es el sistema al que el usuario intenta acceder, como Salesforce, una plataforma de reservas, una intranet u otro sistema empresarial.
El punto que suele causar confusión es la confianza. La aplicación no necesita recopilar y comprobar la contraseña por sí misma. Confía en que el IdP realice ese trabajo correctamente y, a continuación, acepta el resultado.
Lo que realmente significa la relación de confianza
Auth0 explica el SSO claramente en términos empresariales: el IdP autentica al usuario una vez y, a continuación, emite un artefacto de sesión o token que los proveedores de servicios de confianza validan para el acceso posterior. En la práctica, se redirige al usuario al IdP, se le autentica allí y se le devuelve a cada aplicación sin que se le vuelvan a pedir las credenciales. La guía de Auth0 sobre cómo funciona el inicio de sesión único es especialmente relevante en entornos del Reino Unido que utilizan Entra ID en sistemas SaaS e internos.
Una forma práctica de leer esto es la siguiente:
- Un usuario abre una aplicación.
- La aplicación comprueba si un IdP de confianza ya ha autenticado a ese usuario.
- Si no existe ninguna sesión activa, el usuario inicia sesión con el IdP.
- El IdP confirma la identidad y devuelve una prueba que la aplicación puede validar.
- Otros sistemas conectados pueden aceptar esa misma prueba durante la sesión.
Regla práctica: El SSO no convierte todos los sistemas en una única plataforma. Ofrece a múltiples sistemas un único lugar para verificar la identidad.
Por qué esto es importante fuera de las aplicaciones web
Aquí es también donde el SSO se convierte en algo más que una comodidad para el SaaS. Una vez centralizada la identidad, el mismo modelo puede utilizarse para algo más que sesiones de navegador. También puede definir cómo se controla el acceso a los servicios internos y, con el diseño adecuado, cómo se unen los usuarios a la red inalámbrica corporativa.
Esto es clave para las operaciones de TI. Una aplicación de finanzas, una sesión de VPN y una conexión WiFi de un empleado pueden ser servicios diferentes, pero todos empiezan con la misma pregunta: ¿quién es este usuario y se le debe permitir la entrada? Cuando Microsoft Entra ID u Okta responden a esa pregunta de forma coherente, la política de acceso resulta más fácil de gestionar tanto en las aplicaciones como en los puntos de entrada a la red.
Para los equipos que siguen ofreciendo la WiFi del personal con una contraseña compartida, esto supone un cambio importante. En lugar de autenticar un dispositivo con una contraseña que todo el mundo conoce, se autentica a una persona o a un dispositivo gestionado frente a una fuente de identidad de confianza. Esto proporciona un control más estricto, pistas de auditoría más claras y una forma más limpia de revocar el acceso cuando cambian las funciones o finaliza la relación laboral.
Cómo funciona el SSO: Los protocolos principales
La experiencia de usuario parece sencilla. Por debajo, el SSO depende de protocolos estándar que permiten a una aplicación confiar en una decisión de identidad tomada en otro lugar.
Para un responsable de TI de una empresa, la pregunta práctica no es solo "¿qué es el SSO?", sino "¿cómo acepta un sistema la prueba de otro sistema sin pedir al usuario que vuelva a iniciar sesión?". La respuesta depende de un pequeño conjunto de protocolos que mueven los datos de identidad entre la aplicación, el proveedor de identidad y, a veces, el propio dispositivo.
Esto va más allá de los inicios de sesión en el navegador. El mismo modelo de confianza utilizado para abrir una aplicación SaaS también puede influir en cómo se conectan los usuarios a las VPN, a las redes cableadas y a la WiFi corporativa cuando esas decisiones de acceso están vinculadas a Microsoft Entra ID, Okta u otra fuente de identidad central.
SAML en palabras sencillas
SAML 2.0 sigue siendo habitual en el SSO empresarial, especialmente para plataformas SaaS consolidadas y sistemas de línea de negocio.
SAML funciona transmitiendo declaraciones de identidad de confianza entre la aplicación y el proveedor de identidad. Un usuario intenta abrir una aplicación. La aplicación lo redirige al IdP. El IdP autentica al usuario y le devuelve una aserción firmada digitalmente. La aplicación comprueba esa firma, acepta la reclamación de identidad y crea una sesión.
Ese flujo se adapta a entornos en los que el navegador realiza la mayor parte del trabajo y la aplicación espera un intercambio formal basado en estándares.
SAML suele ser una opción muy adecuada para:
- SaaS empresarial como aplicaciones de RR. HH., finanzas o de negocio heredadas
- Flujos de trabajo basados en navegador donde los usuarios acceden a los sistemas a través de una sesión web
- Aplicación de políticas centralizada cuando el departamento de TI desea un único lugar para gobernar la autenticación
OAuth y OIDC explicados de forma sencilla
OAuth 2.0 comenzó como una forma de conceder acceso limitado a un recurso sin tener que compartir un conjunto completo de credenciales. Por sí mismo, se centra en la autorización.
OpenID Connect (OIDC) añade la identidad sobre OAuth 2.0. Esto proporciona a las aplicaciones modernas una forma estándar de confirmar quién es el usuario mientras se siguen utilizando patrones de acceso basados en tokens. Si SAML suele encajar mejor con el SaaS tradicional centrado en el navegador, OIDC suele adaptarse mejor a las aplicaciones web más recientes, las aplicaciones móviles y los servicios orientados a API.
En la práctica, OIDC suele resultar más ligero para los equipos de desarrollo modernos porque los tokens funcionan bien en aplicaciones front-end, servicios back-end y clientes móviles. Para el departamento de TI, esto se traduce en menos soluciones provisionales complejas cuando la aplicación no es una sesión de navegador tradicional.
OIDC suele adaptarse a:
- Aplicaciones en la nube modernas
- Aplicaciones móviles y de página única (SPA)
- Entornos con un uso intensivo de API donde los tokens ya forman parte del diseño
Una breve nota sobre Kerberos
También es posible que oiga hablar de Kerberos en los debates sobre SSO. Kerberos está estrechamente vinculado a los entornos tradicionales de Active Directory y a la autenticación local de Windows. Sigue siendo relevante en entornos empresariales internos, especialmente donde los dispositivos unidos al dominio y las aplicaciones heredadas siguen siendo habituales.
Dicho esto, muchos proyectos de SSO actuales se centran en la identidad federada a través de servicios híbridos y en la nube. En esos casos, SAML y OIDC suelen recibir más atención porque se conectan de forma más natural con las plataformas SaaS y los servicios accesibles externamente.
SAML frente a OIDC de un vistazo
| Característica | SAML 2.0 | OAuth 2.0 / OIDC |
|---|---|---|
| Función principal | Autenticación para aplicaciones web empresariales | Autorización con identidad añadida a través de OIDC |
| Caso de uso común | SaaS establecido y aplicaciones empresariales basadas en navegador | Aplicaciones web modernas, aplicaciones móviles, API |
| Formato | Aseveraciones basadas en XML | Flujos basados en tokens |
| Flujo típico | Redirección al IdP, autenticación, devolución de la aseveración firmada | Redirección o flujo de tokens, luego la aplicación utiliza tokens para la identidad y el acceso |
| Mejor encaje | Integraciones tradicionales de SSO empresarial | Arquitecturas más recientes nativas de la nube y centradas en aplicaciones |
Lo que realmente importa a un responsable de TI
Los nombres de los protocolos importan menos que las decisiones de diseño. Necesita respuestas claras a cuatro preguntas operativas:
- Qué aplicaciones son compatibles con SAML o OIDC
- Qué IdP actuará como su plano de control central
- Cómo se aplicarán el tiempo de espera de la sesión, MFA y el acceso condicional
- Si el acceso a la red, incluido el WiFi para el personal, también debe validar la identidad con esa misma fuente
Ese último punto es donde el SSO resulta especialmente útil para los equipos de infraestructura. Si su plataforma inalámbrica puede utilizar la misma capa de identidad que su entorno SaaS, la política de acceso se vuelve más coherente desde la página de inicio de sesión hasta el extremo de la red. Esa es una de las razones por las que muchos equipos que analizan los beneficios del inicio de sesión único para el control de acceso y las operaciones también empiezan a estudiar la autenticación WiFi basada en la identidad, y no solo los inicios de sesión en aplicaciones web.
Cómo evaluar los beneficios y los inconvenientes de seguridad
El SSO suele venderse como una función de comodidad para el usuario. Eso es restarle valor. Si se hace correctamente, es un modelo de control de acceso que puede mejorar la experiencia del usuario y, al mismo tiempo, reforzar la seguridad operativa.
Okta señala que la ventaja técnica del SSO no es solo la comodidad. Reduce la proliferación de contraseñas y los inicios de sesión repetidos que aumentan la carga del servicio de soporte y la fricción de los usuarios. El análisis de Okta sobre la seguridad del inicio de sesión único también destaca un punto que preocupa a los arquitectos: si la sesión del IdP queda invalidada, las aplicaciones conectadas pueden denegar el acceso en la siguiente comprobación del token.
Dónde se refleja el valor empresarial
El primer beneficio es un acceso más sencillo. Los usuarios inician sesión una vez, empiezan a trabajar antes y dejan de ver la autenticación como un obstáculo diario.
El segundo es un control centralizado más sólido. El departamento de TI puede aplicar MFA, acceso condicional, políticas de sesión y revocación desde una única capa de identidad, en lugar de tener que configurar los ajustes de cada aplicación de forma individual.
Un tercer beneficio es una gestión más fluida de las altas, bajas y cambios de puesto del personal. Cuando la identidad está centralizada, la incorporación y desvinculación de los empleados se vuelven más coherentes. Esa es una de las razones por las que los equipos que exploran los beneficios de single sign-on suelen conectar los proyectos de SSO con un trabajo de gobernanza de la identidad más amplio.
Los inconvenientes que debe tomarse en serio
Existe una preocupación real sobre el control total de los accesos. Si un atacante compromete el inicio de sesión principal del usuario, el radio de impacto puede ser mayor, ya que una sola cuenta puede dar acceso a muchos sistemas.
También existe un riesgo de resiliencia. Si el IdP no está disponible, el acceso a los servicios conectados puede verse interrumpido. Y la integración no siempre es limpia. Las aplicaciones más antiguas, los sistemas especializados y los servicios de red local no siempre encajan perfectamente en un modelo moderno de SSO.
La pregunta correcta no es si el SSO tiene inconvenientes. Es si prefiere gestionar esos inconvenientes de forma centralizada o seguir gestionando decenas de ellos por separado.
Mitigaciones comunes
Utilice un enfoque por capas:
- Proteja fuertemente el IdP con MFA, acceso condicional, confianza en el dispositivo y controles de administración estrictos.
- Planifique la resiliencia para que un problema en el IdP no se convierta en una parálisis para toda la organización.
- Realice el despliegue por fases, comenzando con las aplicaciones de alto valor y grupos de usuarios claros.
- Revise el acceso con regularidad para que los permisos obsoletos no sobrevivan mucho tiempo después de ser necesarios.
Un despliegue de SSO deficiente puede centralizar los problemas. Uno fuerte centraliza el control.
SSO más allá de las aplicaciones web: acceso a redes y WiFi
La mayoría de los artículos se limitan al SaaS. Eso es útil, pero incompleto. En entornos reales, el personal no solo necesita acceso a las aplicaciones. Necesitan un acceso seguro a la red cuando llegan a las instalaciones, conectan un portátil gestionado, abren una tableta en una sucursal o se desplazan entre propiedades.
Ahí es donde la conversación sobre el SSO se vuelve más interesante. El mismo proveedor de identidad que gestiona el acceso a Microsoft 365, los sistemas de recursos humanos o los paneles internos también puede convertirse en la fuente de verdad para las políticas de autenticación inalámbrica.
Optimal IdM informa que el 52% de los profesionales de TI en América del Norte utilizan SSO para la gestión de identidades en su análisis sobre la adopción del inicio de sesión único . Para las organizaciones del Reino Unido con múltiples sedes o propiedades, ese nivel de madurez es fundamental porque el personal a menudo necesita un acceso seguro a los sistemas compartidos sin tener que iniciar sesión repetidamente.
El SSO de aplicaciones y la identidad de red están relacionados, pero no son idénticos
Un punto de confusión habitual para los lectores es que el SSO para aplicaciones y el acceso a la red basado en la identidad son conceptos conectados, pero no utilizan el mismo mecanismo.
El SSO de aplicaciones normalmente significa que el usuario se autentica una vez con un IdP y recibe un token o sesión aceptada por las aplicaciones conectadas. El acceso a la red suele utilizar controles diferentes, como certificados de dispositivo, métodos de autenticación inalámbrica, políticas respaldadas por directorios y comprobaciones de estado o confianza del dispositivo.
Lo que los une es la fuente de identidad. Si Entra ID u Okta ya saben quién es el usuario, a qué grupo pertenece y si su dispositivo está gestionado, puede utilizar ese contexto de identidad para decidir si debe unirse a la red del personal.
Cómo se ve esto en la WiFi corporativa
En un diseño maduro, el personal no introduce en absoluto una contraseña WiFi compartida. Su dispositivo gestionado por la organización está registrado, es de confianza y está asociado a su identidad. Cuando entran en el edificio, el dispositivo se conecta al SSID seguro correspondiente mediante autenticación empresarial basada en certificados o equivalente.
Eso cambia mucho a nivel operativo:
- Las contraseñas compartidas desaparecen, por lo que una credencial filtrada no afecta a toda la red de empleados.
- El acceso se vuelve adaptado a los roles, porque la política puede seguir a los grupos de identidad.
- La revocación es más rápida, porque cuando cambia el acceso al directorio, el acceso a la red puede cambiar con él.
- El roaming se vuelve más sencillo, especialmente en instalaciones con varias sedes donde los usuarios esperan la misma experiencia en todas partes.
Por qué esto importa en hostelería, comercio minorista y sanidad
Estos sectores están llenos de casos excepcionales. Hay trabajadores por turnos, dispositivos compartidos, personal de agencias, equipos itinerantes y una mezcla constante de necesidades de acceso corporativo, semicorporativo y de invitados.
Un grupo hotelero puede querer que una sola identidad de personal rija el acceso al PMS, las aplicaciones de gestión interna y la WiFi interna segura de todos los establecimientos. Una cadena de tiendas de comercio minorista puede querer que los dispositivos de mano gestionados se conecten automáticamente a la WiFi de la tienda mientras el tráfico de invitados permanece aislado. Un proveedor de servicios sanitarios puede querer una separación más sólida entre los usuarios clínicos, los visitantes y los dispositivos conectados.
Aquí es también donde las network access control solutions entran en juego. Ayudan a extender la política de identidad desde la capa de aplicación hasta la capa de red.
Dónde encaja Purple
Una opción práctica es Purple, que admite redes basadas en identidad para el personal y entornos multiinquilino, incluyendo integraciones con Entra ID, Google Workspace y Okta para un acceso seguro sin depender de contraseñas compartidas. Ese tipo de enfoque es útil cuando se desea que la identidad de la aplicación y la identidad de la red funcionen desde la misma fuente de verdad.
SSO en su sector Casos de uso prácticos
La forma más sencilla de ver el valor del SSO es fijarse en el trabajo diario, no en los diagramas de arquitectura.
Hostelería
Un director de operaciones hoteleras empieza el día en un establecimiento y lo termina en otro. Necesita acceso a la programación, a un sistema de gestión hotelera, a los documentos compartidos y a la WiFi interna en ambas ubicaciones.
Con SSO, esa identidad los sigue. Inician sesión una vez y los sistemas aprobados reconocen esa sesión. Si la organización también vincula el acceso a la red con el mismo origen de identidad, su dispositivo gestionado se conecta a la WiFi del personal sin necesidad de que nadie envíe el último password por mensaje de texto al gerente de guardia.
Retail
Un gerente regional entra en una tienda con una tableta. Necesita acceder de inmediato a los paneles de ventas, las herramientas de stock y las aplicaciones de comunicación interna.
En una configuración fragmentada, cada parada puede suponer otra pantalla de inicio de sesión, otra contraseña caducada o una llamada al servicio de asistencia. En un modelo basado en la identidad, la tableta se autentica de forma limpia, el acceso refleja el rol del usuario y el personal de la tienda no tiene que compartir credenciales locales para trabajar.
Un buen SSO no hace que el acceso sea invisible. Hace que el acceso legítimo sea predecible.
Sector sanitario
Un clínico comienza su turno y necesita un acceso rápido y controlado a los sistemas principales. Es posible que a lo largo del día se mueva entre estaciones de trabajo, dispositivos compartidos y segmentos de red restringidos.
Aquí, el SSO ayuda a reducir los inicios de sesión repetidos en las aplicaciones aprobadas, mientras que los controles de red basados en la identidad ayudan a garantizar que los usuarios y dispositivos correctos se conecten a los entornos inalámbricos adecuados. Esa separación es importante. El acceso clínico, el acceso de invitados y el acceso de dispositivos no deben gestionarse de la misma manera.
Propiedades multiinquilino y campus
En residencias de estudiantes, centros de negocios y propiedades de uso mixto, el personal y los residentes suelen coexistir en la misma infraestructura física, pero nunca deberían compartir el mismo modelo de acceso.
El personal puede necesitar sistemas del edificio, herramientas de soporte y aplicaciones de administración interna. Los residentes o inquilinos necesitan una conectividad fiable, pero no acceso a las plataformas operativas. En este contexto, el diseño de la identidad es lo más importante. El SSO puede dar soporte al acceso de la plantilla, mientras que las políticas de identidad de red independientes mantienen aislado el tráfico de inquilinos e invitados.
Implementación de SSO y mejores prácticas
Un proyecto de SSO de éxito empieza con una decisión: elegir el proveedor de identidad que actuará como plano de control. Para muchas organizaciones, se trata de Microsoft Entra ID u Okta, porque esas plataformas ya están estrechamente vinculadas al ciclo de vida del usuario, la MFA y las políticas de dispositivos.
El despliegue debe ser progresivo. Empiece con las aplicaciones más importantes y los grupos de usuarios que más se vayan a beneficiar. Elimine las cuentas duplicadas, defina correctamente los grupos de roles y pruebe el comportamiento de las sesiones antes de ampliar el alcance.
Los controles más importantes
Unas pocas prácticas marcan la diferencia entre una demostración atractiva y un despliegue duradero:
- Exija MFA en el punto de inicio de sesión principal. Si un solo inicio de sesión puede proporcionar acceso a muchos recursos, ese inicio de sesión necesita una protección más sólida.
- Diseñe los procesos de salida en torno a la revocación inmediata. La identidad centralizada solo ayuda si los cambios en las cuentas se aplican rápidamente.
- Revise el acceso por rol. El SSO puede hacer que los excesos de privilegios sean más difíciles de detectar si nadie comprueba quién sigue teniendo acceso.
- Planifique ante posibles caídas del IdP. Sepa qué ocurre si su servicio de identidad no está disponible y qué sistemas requieren una gestión de contingencia.
Sepa cuándo el SSO no es la herramienta adecuada
Este punto suele pasarse por alto en muchas explicaciones genéricas. OneLogin señala una distinción creciente entre el SSO para empleados y el acceso para invitados o dispositivos en implementaciones reales, y plantea una pregunta muy útil para los compradores en su explicación sobre cómo funciona el inicio de sesión único : ¿cuándo es el SSO la herramienta equivocada y cuándo debería aplicarse la identidad al acceso a la red en lugar del inicio de sesión en aplicaciones?
Esto es de gran importancia en el diseño de redes WiFi. El personal a menudo debe utilizar un acceso basado en políticas y vinculado a la identidad. Los invitados, por lo general, necesitan algo más ligero, sencillo y separado. Intentar forzar cada problema de acceso a través del SSO para empleados crea fricciones donde no son necesarias.
Si está evaluando el SSO como parte de una estrategia de acceso más amplia, incluya en la misma conversación las aplicaciones, el WiFi del personal, el registro de invitados, los dispositivos compartidos y los flujos de trabajo de revocación. Ahí es donde se suelen conseguir las mayores ventajas operativas.
Si está rediseñando el acceso en todas sus aplicaciones, el WiFi para el personal, el registro de invitados o las redes multiinquilino, merece la pena echar un vistazo a Purple . Proporciona red basada en identidad que puede funcionar con plataformas como Entra ID, Okta y Google Workspace, ayudando a los equipos a sustituir las contraseñas compartidas y los portales cautivos obsoletos por un acceso controlado para el personal, los invitados y los residentes.
