Inicio de sesión único para una instalación on-premise

Esta página es para operadores de una instalación on-premise de MonoChat. Explica cómo permitir que su equipo inicie sesión con el proveedor de identidad (IdP) de su empresa mediante OpenID Connect (OIDC), por ejemplo Microsoft Entra ID, Okta, Keycloak, AD FS o Google Workspace.

El inicio de sesión único se configura para toda la instalación en los ajustes del servidor, no por organización. Una cuenta de MonoChat puede pertenecer a varias organizaciones, y se inicia sesión antes de elegir una. Iniciar sesión da una cuenta, no acceso: una persona solo ve una organización después de que esta la invite y le asigne un rol.

Cómo funciona el inicio de sesión

Cuando alguien hace clic en el botón SSO de la página de inicio de sesión, MonoChat abre la página de inicio de sesión de su IdP en una ventana emergente. Después de que la persona inicia sesión allí, el IdP devuelve el navegador a MonoChat con un código de un solo uso. El servidor de MonoChat canjea el código por un token de ID y lo comprueba antes de iniciar la sesión de la persona:

• Los endpoints y las claves de firma del IdP se leen de su documento de descubrimiento, <issuer>/.well-known/openid-configuration, en cada inicio de sesión.
• El inicio de sesión usa el flujo de código de autorización con PKCE (S256), un state y un nonce. Una solicitud de inicio de sesión es válida durante 10 minutos y se puede usar una vez.
• El token de ID debe estar firmado con una de las claves del IdP y contener su emisor (iss), su ID de cliente (aud), el nonce de la solicitud y una caducidad (exp) que no haya pasado.
• El token de ID debe contener la dirección de correo electrónico de la persona (email). El inicio de sesión se rechaza cuando el IdP indica que la dirección no está verificada (email_verified: false).

1. Registre MonoChat en su proveedor de identidad

Cree una aplicación (un cliente) para MonoChat en su IdP con estos valores:

Ajuste en el IdP	Valor
Tipo de aplicación	Aplicación web con secreto de cliente (cliente confidencial)
URI de redirección de inicio de sesión	https://<your MonoChat domain>/api/oauth/oidc/redirect
Tipo de concesión	Código de autorización
Ámbitos (scopes)	openid email profile
Autenticación del cliente en el endpoint de token	Secreto de cliente enviado con autenticación HTTP Basic (client_secret_basic)

Asegúrese de que el token de ID contenga la claim email. Anote el ID de cliente, el secreto de cliente y el emisor. El emisor es el valor issuer del documento de descubrimiento del IdP. Formas habituales:

Proveedor de identidad	Emisor (issuer)
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 su valor issuer exactamente, incluida una / final si la tiene. MonoChat no inicia la sesión de nadie cuando los dos difieren.

2. Añada los ajustes

Añada los bloques oidc a los ajustes del servidor y reinicie MonoChat. El bloque público va bajo public.oauth y el bloque secreto bajo oauth:

{
  "oauth": {
    "oidc": {
      "clientSecret": "<client secret>",
      "autoCreateAccounts": true,
      "allowedEmailDomains": ["company.com"]
    }
  },
  "public": {
    "oauth": {
      "oidc": {
        "issuer": "https://login.microsoftonline.com/<tenant id>/v2.0",
        "clientId": "<client id>",
        "redirectPath": "/api/oauth/oidc/redirect",
        "scope": "openid email profile",
        "buttonLabel": "Sign in with Company SSO"
      }
    }
  }
}

Ajuste	Qué hace
public.oauth.oidc.issuer	El emisor del paso 1
public.oauth.oidc.clientId	El ID de cliente del paso 1
public.oauth.oidc.redirectPath	La ruta del URI de redirección del paso 1
public.oauth.oidc.scope	Los ámbitos que solicita MonoChat
public.oauth.oidc.buttonLabel	El texto del botón de inicio de sesión. Vacío muestra "Iniciar sesión con SSO" en el idioma de la persona
oauth.oidc.clientSecret	El secreto de cliente. Permanece en el servidor
oauth.oidc.autoCreateAccounts	true crea la cuenta de MonoChat en el primer inicio de sesión SSO de una persona, incluso cuando el registro es solo por invitación (public.disableSignup)
oauth.oidc.allowedEmailDomains	Solo las personas cuya dirección de correo pertenece a uno de estos dominios pueden iniciar sesión con SSO. Omítalo para permitir todos los dominios

A continuación, el botón SSO aparece en la página de inicio de sesión.

Quién puede iniciar sesión

• Personas nuevas. Con autoCreateAccounts: true, el primer inicio de sesión SSO de una persona crea su cuenta. Sin él, la cuenta solo se crea cuando public.disableSignup está desactivado o la persona inicia sesión desde una invitación.
• Personas que ya tienen una cuenta con la misma dirección de correo. Con oauth.autoMerge: true, el primer inicio de sesión SSO vincula el SSO a la cuenta existente, pero solo cuando el token de ID indica que la dirección está verificada (email_verified: true). En los demás casos, y siempre sin autoMerge, MonoChat pide a la persona que inicie sesión una vez con su contraseña y entonces vincula el SSO a la cuenta; aceptar una invitación a una organización también lo vincula. Microsoft Entra ID y AD FS no envían email_verified, así que con ellos mantenga permitido el inicio de sesión con contraseña hasta que todos hayan vinculado el SSO, o vuelva a invitar a las personas.
• Dominios permitidos. Con allowedEmailDomains, se rechaza una dirección de cualquier otro dominio. Para Google Workspace (emisor https://accounts.google.com), MonoChat comprueba la claim hd, el dominio de Workspace de la cuenta, en lugar de la dirección de correo, porque una cuenta personal de Google puede usar una dirección de cualquier dominio.

Haga que el SSO sea el único método de inicio de sesión

1. Establezca public.auth.methods en ["oidc"]. La página de inicio de sesión mostrará solo el botón SSO, y el servidor rechazará el inicio de sesión con contraseña y con redes sociales.
2. Los usuarios root super (usuarios con el rol root super en la organización raíz) pueden seguir iniciando sesión con su contraseña en /auth/signin?fallback=1, para que la instalación nunca quede bloqueada si el IdP no está disponible.
3. Para impedir que las nuevas cuentas SSO abran sus propias organizaciones, establezca public.disableTenantCreation en true. Entonces solo las personas con el rol adecuado en una organización pueden crear organizaciones bajo ella.

Red

• Mantenga /api/oauth/oidc/authorize y su redirectPath accesibles para las personas que inician sesión. Ambos se abren en su navegador.
• El servidor de MonoChat debe poder acceder por HTTPS al documento de descubrimiento, al endpoint de token y al conjunto de claves (jwks_uri) de su IdP.

Limitaciones

• La aplicación móvil de MonoChat todavía no ofrece SSO. Si hace que el SSO sea el único método de inicio de sesión, los agentes no podrán iniciar sesión en la aplicación móvil.
• Cerrar sesión en MonoChat no cierra la sesión de la persona en el IdP, y cerrar sesión en el IdP todavía no la cierra en MonoChat.

Compruebe su configuración

1. Abra la página de inicio de sesión y haga clic en el botón SSO. Inicie sesión en su IdP; la ventana emergente se cierra y queda conectado a MonoChat.
2. Inicie sesión con una persona que aún no tenga cuenta de MonoChat y confirme que la cuenta se crea (o se rechaza, si no activó autoCreateAccounts).
3. Si configuró allowedEmailDomains, pruebe con una persona de otro dominio y confirme que se rechaza el inicio de sesión.
4. Si configuró public.auth.methods, confirme que se rechaza un inicio de sesión con contraseña y que un usuario root super aún puede iniciar sesión en /auth/signin?fallback=1.