SSO, llaves de acceso y 2FA para reservar escritorios

Imagine a Kasia, la única persona de TI en una empresa de 180 personas que acaba de pasar a una oficina híbrida. Es lunes, son las 8:40. Ya hay tres tickets esperando: un compañero ha olvidado la contraseña de la herramienta de reserva de escritorios, otra no encuentra el correo con su código de inicio de sesión, y un responsable de equipo pregunta si el contratista que se marchó el viernes todavía puede reservar una plaza de parking. Kasia ha pasado dos años poniendo todas las aplicaciones detrás del proveedor de identidad de la empresa. La herramienta de reserva de escritorios es la única que aún tiene sus propias contraseñas.

Así funciona el inicio de sesión en Desk & Park, esto es lo que Kasia configuraría y este es el único punto en el que el producto rompe deliberadamente la regla de "todo a través del SSO". Todo ello está disponible en todos los planes, incluido el plan gratuito Start.

Paso 1: conectar el proveedor de identidad (SSO con OpenID Connect)

Desk & Park admite el inicio de sesión único mediante OpenID Connect, el estándar que usan Microsoft Entra ID, Google Workspace, Okta y la mayoría de los demás proveedores de identidad. El flujo es el de código de autorización con PKCE, la variante recomendada para aplicaciones web.

Kasia abre Configuración de la organización → Inicio de sesión único (SSO) y rellena cuatro campos:

1. URL del emisor: para Google https://accounts.google.com, para Entra https://login.microsoftonline.com/<tenant-id>/v2.0, o el emisor de cualquier otro proveedor OIDC.
2. ID de cliente y Secreto de cliente del registro de aplicación que crea en la consola de su proveedor. El secreto se guarda cifrado y no se vuelve a mostrar; para cambiarlo, escribe uno nuevo.
3. Dominio de correo permitido (opcional). Si se define, solo las direcciones de ese dominio pueden iniciar sesión por SSO, de modo que una cuenta personal que casualmente exista en el proveedor no entra.
4. La tarjeta muestra el URI de redirección que hay que pegar en el registro de la aplicación.

Marca Activar el inicio de sesión por SSO y guarda. La página de inicio de sesión muestra ahora Iniciar sesión con SSO, y la compañera que olvidó su contraseña usa la misma cuenta de Microsoft o Google que para el correo. Una organización conecta un solo proveedor.

Lo que el SSO no hace por sí solo: crear cuentas

El primer inicio de sesión por SSO no crea una cuenta. Si alguien se autentica correctamente en el proveedor pero no tiene cuenta en Desk & Park, vuelve a la página de inicio de sesión con un mensaje que le indica que pida una invitación a su administrador. Las cuentas las crea un administrador: por invitación una a una, importadas desde una lista o aprovisionadas automáticamente desde Entra ID u Okta mediante SCIM, como describimos en aprovisionamiento SCIM y offboarding.

Esto importa para el tercer ticket de Kasia: bloquear a alguien en el proveedor es solo la mitad del offboarding. La otra mitad es desactivar la cuenta de Desk & Park y cerrar sus sesiones, que es lo que hace SCIM cuando la persona se deshabilita en el directorio.

Quién comprueba el segundo factor en un inicio de sesión por SSO

Cuando alguien inicia sesión por SSO, el proveedor de identidad ya lo ha autenticado, así que Desk & Park no añade su propio paso de código encima. El segundo factor es el que exija su proveedor. Si su política de Entra u Okta pide MFA, esa es la MFA por la que pasan sus empleados.

Paso 2: la excepción deliberada, los administradores

Esta es la parte que sorprende a algunos equipos de TI: las cuentas de administrador no pueden iniciar sesión por SSO. Es intencionado.

Un inicio de sesión por SSO identifica a la persona por su dirección de correo electrónico. Si un proveedor de identidad llega a estar mal configurado o comprometido, quien lo controle podría presentar la dirección de correo de un administrador y entrar en la consola de administración del sistema de reservas. Para mantener esa puerta cerrada, los administradores usan los factores propios de la plataforma: una contraseña, una llave de acceso o un código por correo electrónico, seguidos del código de su aplicación de autenticación una vez que han activado el doble factor.

Así que la regla práctica para Kasia es esta: todas las cuentas de administrador deben activar la autenticación de dos factores en Configuración → Seguridad, empezando por la suya. El producto no lo impone, y por eso debe estar en su lista de comprobación.

Paso 3: llaves de acceso para quienes odian las contraseñas

Una llave de acceso (passkey, WebAuthn) permite iniciar sesión con la huella dactilar, el reconocimiento facial o el PIN del dispositivo, sin contraseña que recordar ni que pueda robarse con phishing. Cada usuario añade la suya en Configuración → Seguridad → Llaves de acceso ("Añadir una llave de acceso"), y puede ponerle nombre si quiere ("MacBook", "iPhone"). La lista muestra cuándo se añadió y cuándo se usó por última vez cada llave, y cualquiera de ellas puede eliminarse.

Un detalle que importa en las revisiones de seguridad: una llave de acceso usada con verificación del usuario (la comprobación de huella, cara o PIN) cuenta por sí sola como dos factores y completa el inicio de sesión. Una llave de acceso usada sin verificación del usuario se trata solo como posesión, de modo que una cuenta con el doble factor activado sigue pasando después por el paso del código.

Paso 4: doble factor con una aplicación de autenticación

El doble factor en Desk & Park es TOTP: el código de seis dígitos de una aplicación de autenticación. Cada usuario lo activa en Configuración → Seguridad; a partir de entonces, cada inicio de sesión con contraseña, con código por correo o con una llave de acceso sin verificación del usuario pide el código.

El usuario recibe además códigos de recuperación de un solo uso: si pierde el teléfono, un código le permite entrar y después queda gastado. Los códigos pueden regenerarse, y activar o desactivar el doble factor queda anotado en el registro de seguridad.

Paso 5: sesiones que puede ver y cerrar

En Configuración → Seguridad → Sesiones activas, cada usuario ve dónde tiene la sesión iniciada (navegador, sistema operativo, dirección IP, hora de inicio) y puede revocar cualquier sesión o Cerrar sesión en todos los dispositivos.

Entre bastidores, otros dos mecanismos trabajan en silencio:

• Rotación del token de actualización. Cada vez que se renueva una sesión, el token antiguo se sustituye. Si vuelve a presentarse un token ya usado, señal de que se ha copiado, se cierra la sesión entera.
• Bloqueo tras fallos repetidos. Tras varios intentos fallidos, los siguientes intentos quedan bloqueados durante un tiempo, y el bloqueo aparece en el registro de seguridad.

Consejos prácticos para el despliegue

• Empiece por los administradores. Antes de anunciar el SSO, asegúrese de que todos los administradores tienen activado el doble factor y han añadido una llave de acceso. No podrán usar el SSO, así que su propio inicio de sesión tiene que ser robusto.
• Defina el dominio de correo permitido si su proveedor de identidad también contiene cuentas de invitados o personales.
• Decida cómo se crean las cuentas. Para una oficina pequeña, las invitaciones bastan. Para algo mayor, conecte SCIM para que las altas y las bajas lleguen desde el directorio.
• Haga un anuncio breve. "Use Iniciar sesión con SSO, con la misma cuenta que su correo" es suficiente.
• Revise de vez en cuando el registro de seguridad. Los inicios de sesión, los fallos, los bloqueos y los cambios del doble factor aparecen en el registro de auditoría de administración; lo describimos en registro de auditoría y acceso del soporte.

Alcance: lo que esto no hace

Para ser claros con las expectativas: el inicio de sesión único es solo OpenID Connect, así que no hay SAML. No existe una política para toda la organización que obligue a todos los usuarios a usar el doble factor, ni un tiempo de espera de sesión configurable, ni una lista de IP permitidas, ni un modo "solo SSO" que desactive los demás métodos de inicio de sesión. El doble factor es una decisión de cada usuario, y por eso la lista de comprobación anterior empieza por los administradores. Dónde se guardan los propios datos es otro tema, tratado en por qué los datos de su oficina exigen una base de datos aislada.

Los planes y límites están en la página de precios; la puesta en marcha de una oficina completa se describe en la guía de incorporación.

Preguntas frecuentes

¿Qué proveedores de identidad funcionan con el SSO de Desk & Park?

Cualquier proveedor compatible con OpenID Connect, incluidos Microsoft Entra ID, Google Workspace y Okta. Una organización conecta un solo proveedor. SAML no es compatible.

¿El primer inicio de sesión por SSO crea una cuenta automáticamente?

No. La cuenta tiene que existir antes: un administrador invita a la persona, importa una lista o aprovisiona las cuentas mediante SCIM desde Entra ID u Okta. Quien no tiene cuenta vuelve a la página de inicio de sesión con un mensaje que le indica que se dirija a su administrador.

¿Por qué los administradores no pueden iniciar sesión por SSO?

Porque un inicio de sesión por SSO identifica la cuenta por el correo electrónico, y un proveedor de identidad mal configurado o comprometido no debe poder abrir la consola de administración. Los administradores inician sesión con una contraseña, una llave de acceso o un código por correo, seguidos del código de su aplicación de autenticación una vez activado el doble factor.

¿Podemos obligar a todo el mundo a usar la autenticación de dos factores?

No desde el producto. Cada usuario activa el doble factor en Configuración → Seguridad. Los empleados que inician sesión por SSO pasan por la MFA que exija su proveedor de identidad; en el caso de los administradores, activar el doble factor debería formar parte de su lista de comprobación de la puesta en marcha.

¿El SSO está incluido en el plan gratuito?

Sí. El SSO, las llaves de acceso, el doble factor y la lista de sesiones activas están disponibles en todos los planes, incluido Start.