Configuración de SSO
Configuración de SSO
Esta guía está dirigida al administrador de TI que conecta un proveedor de identidad (IdP) corporativo a InterMIND. Una vez configurado, los miembros inician sesión desde la página de inicio de sesión habitual: Iniciar sesión con SSO → correo corporativo → su IdP → de vuelta en InterMIND.
Disponible en: planes Business y Enterprise Configurado por: propietario o administrador del equipo Protocolo: OpenID Connect (OIDC). El inicio de sesión con SAML 2.0 está en desarrollo — la configuración SAML se almacena, pero todavía no se puede utilizar para iniciar sesión.
Requisitos previos
- Un dominio verificado — verifique primero el dominio de su correo electrónico mediante un registro DNS TXT (consulte Gestión de dominios). El inicio de sesión con SSO solo acepta cuentas cuyo dominio de correo haya sido verificado por su equipo; este es el límite del tenant.
- Un IdP que admita OIDC con discovery — debe servir
/.well-known/openid-configurationbajo la URL del Issuer. Okta, Microsoft Entra ID y Google lo hacen.
Qué registrar en su IdP
Cree una OIDC Web Application en su IdP con:
| Ajuste | Valor |
|---|---|
| Redirect URI (callback) | https://intermind.com/api/auth/sso/callback — también se muestra en la tarjeta de SSO después de seleccionar OIDC |
| Grant type | Authorization Code (PKCE S256 se utiliza automáticamente) |
| Scopes | openid email profile |
El token de ID que emita su IdP debe incluir el email del usuario, y el dominio de ese correo debe ser uno de sus dominios verificados — de lo contrario se rechazará el inicio de sesión.
A continuación, rellene la tarjeta SSO en la página de Integraciones:
| Campo | Qué pegar |
|---|---|
| Display Name | Cualquier etiqueta que sus miembros reconozcan |
| Issuer URL | El issuer de su IdP — la URL que sirve /.well-known/openid-configuration |
| Authorization URL | El authorization_endpoint de ese documento de discovery |
| Client ID / Client Secret | De la aplicación que registró |
El client secret se cifra en reposo y nunca se devuelve al navegador después de guardarlo.
Okta
- Consola de administración → Applications → Create App Integration → método de inicio de sesión OIDC, tipo de aplicación Web Application
- Sign-in redirect URI:
https://intermind.com/api/auth/sso/callback - Asigne los usuarios o grupos que deban tener acceso
- Copie el Client ID y el Client Secret
- En InterMIND: Issuer URL = la URL de su organización en Okta (p. ej.
https://acme.okta.com, o el issuer de su authorization server, comohttps://acme.okta.com/oauth2/defaultsi utiliza uno); Authorization URL = elauthorization_endpointde<issuer>/.well-known/openid-configuration
Microsoft Entra ID (Azure AD)
- Centro de administración de Entra → App registrations → New registration
- Plataforma Web, redirect URI
https://intermind.com/api/auth/sso/callback - Certificates & secrets → New client secret — copie el Value del secreto inmediatamente
- Client ID = el Application (client) ID en la página Overview
- Asegúrese de que el token de ID incluya el correo del usuario: Token configuration → Add optional claim → ID → email
- En InterMIND: Issuer URL =
https://login.microsoftonline.com/<tenant-id>/v2.0; Authorization URL =https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
Google Workspace
No hace falta registrar ninguna aplicación. En la tarjeta de SSO seleccione el tipo de proveedor Google Workspace y guarde — los miembros con sus dominios verificados inician sesión con su cuenta de Google y se unen a su equipo automáticamente. (Google también puede conectarse como un proveedor OIDC genérico con el issuer https://accounts.google.com si prefiere usar credenciales de cliente explícitas.)
Probar la conexión
- Abra la página de inicio de sesión en una ventana privada o de incógnito
- Haga clic en Iniciar sesión con SSO e introduzca un correo corporativo de su dominio verificado
- Será redirigido a su IdP; tras autenticarse, volverá a InterMIND con la sesión iniciada
- El inicio de sesión queda registrado en el registro de auditoría del equipo (exportable desde la página Usuarios) como
auth.logincon el métodosso
Resolución de problemas
| Síntoma | Causa |
|---|---|
| "SSO is not configured" tras introducir el correo | Ninguna configuración de SSO activa coincide con ese dominio de correo — compruebe que el dominio esté verificado y que la tarjeta de SSO esté guardada |
SSO login is not available: plan | El plan del equipo ya no incluye SSO |
SSO login is not available: domain-not-verified | El dominio sigue pendiente de verificación DNS |
SSO login is not available: config-incomplete | Falta el Client ID o el Client Secret — vuelva a guardar la tarjeta de SSO |
SSO login is not available: type-unsupported | La configuración almacenada es SAML — el inicio de sesión con SAML aún no está disponible |
SSO IdP discovery failed | La Issuer URL es incorrecta o no sirve /.well-known/openid-configuration |
| "login session expired, start again" | Han transcurrido más de 5 minutos entre el inicio del proceso de sign-in y el callback del IdP |
| Inicio de sesión rechazado tras la redirección del IdP | El IdP devolvió un correo fuera de sus dominios verificados, o ningún claim email (Entra: añada el claim opcional de email) |
Propiedades de seguridad
Para cuestionarios de seguridad: el flujo de SSO es Authorization Code con PKCE (S256), state y nonce; la firma del token de ID se valida contra el JWKS del IdP, junto con el issuer y la audience; el IdP solo tiene autoridad sobre los dominios verificados mediante DNS — una aserción para cualquier otro correo nunca genera una sesión; el client secret de OIDC está cifrado en reposo; cada inicio de sesión con SSO queda registrado en el registro de auditoría del equipo. Las restricciones de plan, dominio y configuración se aplican en el servidor tanto al iniciar el proceso de sign-in como en el callback.