Inicio de sesión único (SSO) para su plataforma de mensajería con clientes: guía de OpenID Connect para equipos de soporte

El inicio de sesión único (SSO) en una plataforma de mensajería con clientes significa que sus agentes entran con su cuenta de la empresa en su proveedor de identidad, como Microsoft Entra ID, Okta, Keycloak, AD FS o Google Workspace, en lugar de usar una contraseña aparte. El estándar que lo hace posible es OpenID Connect (OIDC). En una instalación on-premise de MonoChat lo configura una sola vez para toda la instalación, lo limita a los dominios de correo electrónico de su empresa y puede convertirlo en la única forma de iniciar sesión.

Los equipos de soporte tienen una razón especial para ocuparse de esto. La cuenta de un agente abre todas las conversaciones de WhatsApp, Instagram y Messenger que puede ver: nombres, números de teléfono, datos de pedidos y, a veces, consultas de salud o de pago. Esa cuenta debe seguir las mismas reglas que el resto de las cuentas de la empresa y debe dejar de funcionar el día en que la persona se va.

Por qué el inicio de sesión importa en un equipo de soporte

Las credenciales robadas o mal utilizadas siguen siendo la vía de entrada más común a una empresa. El Informe de Investigaciones de Brechas de Datos 2025 de Verizon, que analizó 12.195 brechas confirmadas, concluyó que el abuso de credenciales (22 %) y la explotación de vulnerabilidades (20 %) fueron los principales vectores de ataque inicial.

Una plataforma de mensajería con contraseñas propias añade un juego más de credenciales a cada agente: una contraseña más que se puede reutilizar, una cuenta más que se olvida cuando alguien se va, un acceso más que sus reglas de autenticación multifactor (MFA) y de acceso condicional no cubren. Con SSO, la plataforma nunca ve la contraseña. Su proveedor de identidad la comprueba, aplica su MFA y sus políticas de acceso, y le informa a la plataforma quién inició sesión.

Cómo funciona el inicio de sesión con OpenID Connect

OpenID Connect es una capa de identidad sobre OAuth 2.0. El flujo que usa MonoChat es el de código de autorización (authorization code flow):

1. El agente hace clic en el botón de SSO de la página de acceso. MonoChat abre la página de inicio de sesión de su proveedor de identidad en una ventana emergente.
2. El agente inicia sesión allí, con su MFA y sus políticas.
3. El proveedor de identidad devuelve el navegador a MonoChat con un código de un solo uso.
4. El servidor de MonoChat canjea el código por un token de ID (ID token), de servidor a servidor. Los tokens nunca pasan por el navegador.
5. MonoChat comprueba el token de ID y deja entrar al agente.

El token de ID es, según la especificación de OpenID Connect, “a security token that contains Claims about the Authentication of an End-User” (un token de seguridad que contiene afirmaciones sobre la autenticación de un usuario final). MonoChat solo lo acepta cuando:

• está firmado con una de las claves de su proveedor de identidad, leídas de su documento de descubrimiento (<issuer>/.well-known/openid-configuration) en cada inicio de sesión;
• su emisor (iss) es el suyo, su audiencia (aud) es el ID de cliente de MonoChat y su vencimiento (exp) no ha pasado;
• incluye el nonce que MonoChat envió con la solicitud, que vincula el token a este inicio de sesión y evita su reutilización;
• contiene la dirección de correo electrónico de la persona y el proveedor no indica que esa dirección esté sin verificar.

La solicitud también usa PKCE (S256) y un valor state, y una solicitud de inicio de sesión es válida durante 10 minutos y solo puede usarse una vez.

Decida estas cinco cosas antes de activar el SSO

Decisión	Opciones	Qué recomendamos para un equipo de soporte
Quién puede iniciar sesión	Cualquier dominio, o solo los dominios de correo de su empresa	Limitarlo a sus dominios
Qué pasa en el primer inicio de sesión	Crear la cuenta, o aceptar solo a personas invitadas	Crear cuentas si su proveedor de identidad ya controla quién trabaja en la empresa
Cuentas existentes	Vincular el SSO en el primer inicio de sesión cuando el correo está verificado, o después de un inicio de sesión con contraseña	Depende de si su proveedor envía email_verified
Otros métodos de acceso	Mantener contraseñas y acceso con redes sociales, o solo SSO	Solo SSO, cuando todos hayan vinculado el SSO
Quién puede abrir nuevos espacios de trabajo	Cualquiera con una cuenta, o solo personas con el rol adecuado	Desactivar la creación abierta de espacios de trabajo en una instalación corporativa

Anote estas decisiones antes de cambiar cualquier ajuste. Son las preguntas que le hará su equipo de seguridad y las respuestas determinan qué ajustes necesita.

Configure el SSO en una instalación on-premise de MonoChat

El SSO se configura para toda la instalación en los ajustes del servidor, no por espacio de trabajo. La referencia completa es la página de inicio de sesión único del centro de ayuda; aquí va la versión corta.

1. Registre MonoChat en su proveedor de identidad

Cree una aplicación web con un secreto de cliente y asígnele:

• la URI de redirección https://<your MonoChat domain>/api/oauth/oidc/redirect;
• la concesión de código de autorización (authorization code grant);
• los ámbitos (scopes) openid email profile;
• autenticación del cliente con el secreto enviado como HTTP Basic (client_secret_basic).

Asegúrese de que el token de ID incluya la afirmación (claim) email y anote el ID de cliente, el secreto de cliente y el emisor.

2. Copie el emisor exactamente

El emisor es el valor issuer del documento de descubrimiento de su proveedor. Formas habituales:

Proveedor de identidad	Emisor
Microsoft Entra ID	https://login.microsoftonline.com/<tenant id>/v2.0
Okta	https://<your Okta domain>/oauth2/default o https://<your Okta domain>
Keycloak	https://<your Keycloak host>/realms/<realm>
AD FS 2016 o posterior	https://<your AD FS host>/adfs
Google Workspace	https://accounts.google.com

Abra <issuer>/.well-known/openid-configuration en un navegador y copie el valor carácter por carácter, incluida la barra final si la tiene. MonoChat rechaza todos los inicios de sesión cuando los dos valores difieren, que es el motivo más común por el que falla una primera prueba.

3. Agregue los ajustes y reinicie

La parte pública (emisor, ID de cliente, ruta de redirección, ámbitos y texto del botón) va en public.oauth.oidc; el secreto de cliente va en oauth.oidc y se queda en el servidor. Dos opciones de ese bloque reflejan las decisiones de la tabla anterior:

• autoCreateAccounts: true crea la cuenta de MonoChat en el primer inicio de sesión con SSO de una persona, incluso cuando el registro es solo por invitación;
• allowedEmailDomains: ["yourcompany.com"] rechaza toda dirección de otro dominio. En Google Workspace, MonoChat comprueba el dominio de Workspace de la cuenta (la afirmación hd) en lugar de la dirección de correo, porque una cuenta personal de Google puede usar una dirección de cualquier dominio.

El botón dice “Iniciar sesión con SSO” en el idioma de cada persona, o la etiqueta que usted defina, como “Iniciar sesión con Northwind SSO”.

4. Haga del SSO el único método, con seguridad

Cuando todos hayan vinculado el SSO, configure los métodos de inicio de sesión permitidos (public.auth.methods) en ["oidc"]. La página de acceso mostrará entonces solo el botón de SSO y el servidor rechazará el acceso con contraseña y con redes sociales. Los superusuarios root pueden seguir entrando con su contraseña en /auth/signin?fallback=1, de modo que un proveedor de identidad caído nunca bloquea la instalación. Para evitar que las nuevas cuentas de SSO abran espacios de trabajo propios, configure public.disableTenantCreation en true.

5. Pruebe cuatro inicios de sesión

1. Una persona con cuenta: la ventana emergente se cierra y entra.
2. Una persona sin cuenta: se crea la cuenta, o se rechaza si no activó la creación de cuentas.
3. Una persona de otro dominio: se rechaza, si limitó los dominios.
4. Un inicio de sesión con contraseña con solo SSO activado: se rechaza, mientras que el acceso de emergencia root sigue funcionando.

Agentes existentes: cómo se vinculan las cuentas

La mayoría de los equipos activa el SSO con agentes que ya tienen cuenta en MonoChat. MonoChat vincula el SSO a una cuenta existente con la misma dirección de correo electrónico de una de estas dos maneras:

• Automáticamente, en el primer inicio de sesión con SSO, cuando la instalación permite la fusión y el token de ID indica que la dirección está verificada (email_verified: true).
• Tras un inicio de sesión con contraseña, en cualquier otro caso: MonoChat pide a la persona que inicie sesión una vez con su contraseña y vincula entonces el SSO. Aceptar una invitación a un espacio de trabajo también lo vincula.

Microsoft Entra ID y AD FS no envían email_verified. Con ellos, mantenga permitido el acceso con contraseña hasta que todos hayan vinculado el SSO, o vuelva a invitar a las personas, antes de pasar a solo SSO.

El SSO es la identidad; los roles son el acceso

Iniciar sesión da a una persona una cuenta, no acceso a sus conversaciones. Una cuenta de MonoChat puede pertenecer a varios espacios de trabajo, y las personas inician sesión antes de elegir uno. Una persona ve un espacio de trabajo solo después de que la invite y le asigne un rol, y el rol decide a qué canales, conversaciones y ajustes accede. Consulte roles y permisos en la bandeja de entrada del equipo para saber cómo configurarlos.

Esa separación es lo que querrá ver un auditor:

• Alta: el proveedor de identidad crea a la persona; un administrador del espacio de trabajo la invita y elige el rol.
• Cambio de puesto: cambie el rol o el grupo de trabajo en MonoChat; el inicio de sesión no cambia.
• Baja: deshabilite a la persona en el proveedor de identidad y quítela del espacio de trabajo en MonoChat.

Límites que debe tener en cuenta

• La aplicación móvil. La aplicación de MonoChat para Android y iOS todavía no ofrece SSO. Si el SSO es el único método de acceso, los agentes no podrán entrar desde el celular; mantenga otro método para los usuarios móviles o planifique turnos solo en computadora.
• Cierre de sesión. Cerrar sesión en MonoChat no cierra la sesión en el proveedor de identidad, y cerrarla allí todavía no cierra la sesión en MonoChat. Deshabilitar a una persona que se va en el proveedor de identidad impide nuevos inicios de sesión; quítela también del espacio de trabajo.
• Red. Los navegadores de las personas deben poder llegar a /api/oauth/oidc/authorize y a la ruta de redirección, y el servidor de MonoChat debe poder llegar por HTTPS al documento de descubrimiento, al endpoint de tokens y al conjunto de claves de su proveedor. Si además restringe la instalación por IP, tenga presentes esas rutas.

Dónde encaja el SSO en MonoChat

El SSO se configura en los ajustes del servidor de toda una instalación, por lo que hoy pertenece a MonoChat on-premise: la opción Enterprise para equipos que ejecutan la plataforma en sus propios servidores, con su propio LLM y su propia base de datos vectorial. La página Enterprise explica la opción on-premise, y la página de seguridad trata el control de acceso basado en roles, el aislamiento de espacios de trabajo y las certificaciones. Para la parte de datos de un despliegue de IA, consulte la lista de privacidad para chatbots de IA.

Si primero quiere probar el producto, el plan Basic gratuito en app.monochat.ai le da un agente y un canal.

Fuentes

• OpenID Connect Core 1.0, OpenID Foundation, consultado el 4 de noviembre de 2026
• Anuncio del Informe de Investigaciones de Brechas de Datos 2025 de Verizon, consultado el 4 de noviembre de 2026
• Centro de ayuda de MonoChat: inicio de sesión único para una instalación on-premise, consultado el 4 de noviembre de 2026
• Registro de cambios de MonoChat 3.8.43, 2 de noviembre de 2026