Inicio de sesión único (SSO)

El inicio de sesión único permite que todo tu equipo entre en CrunchJunkie con el proveedor de identidad que ya usa tu empresa, ya sea Microsoft Entra ID (Azure AD), Google Workspace, Okta o cualquier proveedor OpenID Connect, en lugar de con una contraseña aparte. Los nuevos compañeros se dan de alta en tu espacio de trabajo automáticamente la primera vez que inician sesión. El SSO está disponible en los planes Pro, Agency y Scale, y lo configura el propietario o un administrador del espacio de trabajo en Ajustes → Inicio de sesión único (SSO). Sin un plan Pro, Agency o Scale activo, el inicio de sesión único se pausa: tu equipo entra con contraseña o con Google, y quien solo haya usado SSO puede crear una contraseña con «¿Has olvidado la contraseña?». Esa contraseña es temporal. Cuando el plan vuelve a estar activo y el SSO funciona, se elimina, las sesiones iniciadas con ella terminan en torno a un minuto después y la persona vuelve a entrar con SSO; le enviamos un correo una sola vez cuando esto ocurre. Una contraseña que la persona ya tuviera antes se conserva. Mientras alguien entra con una contraseña temporal así, no puede cambiar su dirección de correo. Las claves API pertenecen al espacio de trabajo, no a una contraseña, así que no se eliminan: cuando se elimina una contraseña temporal, el registro de auditoría de administración enumera las claves API que esa persona creó mientras tanto, y el propietario o un administrador puede revisarlas en Ajustes → API REST y revocar las que no hagan falta. El propietario o un administrador sigue pudiendo desactivar el SSO, quitar dominios o eliminar la conexión, y el SSO vuelve a funcionar cuando el plan está activo. El SSO es una vía de acceso adicional hasta que lo exijas: con Exigir SSO activado (ver «Exigir SSO» más abajo), los miembros de tus dominios verificados solo pueden iniciar sesión a través de tu proveedor de identidad. Hoy admitimos OpenID Connect, que cubre la gran mayoría de los IdP empresariales. Si tu proveedor solo habla SAML, pregúntanos: SAML está disponible bajo petición en el plan Scale.

En tu proveedor de identidad, crea una aplicación OIDC (OpenID Connect) nueva. Define el URI de redirección con el valor que aparece en Ajustes → Inicio de sesión único (SSO); tiene este aspecto: https://app.crunchjunkie.io/api/auth/sso/callback. Solicita los ámbitos estándar openid, email y profile. Tu IdP te dará tres datos: una URL de emisor (issuer), un ID de cliente y un secreto de cliente. Pégalos en Ajustes → Inicio de sesión único (SSO) y guarda. El secreto se almacena cifrado y no se vuelve a mostrar; para cambiarlo, basta con guardar uno nuevo. Dos configuraciones habituales. Google Workspace: en la consola de Google Cloud crea un ID de cliente OAuth de tipo «Aplicación web», añade allí el URI de redirección y usa https://accounts.google.com como URL de emisor. Microsoft Entra ID: registra una aplicación, añade el URI de redirección como plataforma «Web» y usa https://login.microsoftonline.com/<your tenant id>/v2.0 como URL de emisor. Si tu IdP responde «redirect_uri_mismatch», la dirección registrada allí difiere de la que se muestra en Ajustes → Inicio de sesión único (SSO): cópiala de nuevo, carácter por carácter.

El SSO dirige cada inicio de sesión según el dominio del correo del usuario, así que nos indicas qué dominios son tuyos y demuestras que lo son. Añade un dominio (por ejemplo, acme.com) en Ajustes → Inicio de sesión único (SSO) y te mostraremos un registro TXT de DNS: añádelo al DNS de ese dominio y haz clic en Verificar. Un dominio no dirige ningún inicio de sesión hasta que está verificado, y cada dominio solo puede pertenecer a un espacio de trabajo, de modo que nadie más puede reclamar el tuyo. Un dominio que lleva 30 días sin verificar se libera, para que una reclamación sin terminar no bloquee al verdadero propietario del dominio; si quieres verificarlo después de eso, añádelo de nuevo para obtener un registro TXT nuevo. Añádelo como un registro TXT nuevo en el propio dominio (host @, o vacío), junto a los registros TXT que ya tengas: SPF y otros registros de verificación se quedan como están. Pega el valor completo, incluido el código que va después del signo igual: algunos paneles de DNS cortan un valor pegado en el «=». Los cambios de DNS pueden tardar unos minutos en verse; si Verificar falla, espera y vuelve a intentarlo.

Cuando al menos un dominio esté verificado, activa el SSO. A partir de ahí, el usuario abre la página de inicio de sesión, hace clic en «Continuar con inicio de sesión único (SSO)» (o va directamente a app.crunchjunkie.io/auth/sso), introduce su correo de trabajo y es enviado a tu IdP; después de autenticarse allí (incluido cualquier segundo factor que exija tu IdP), llega a la página de Inicio de CrunchJunkie con la sesión iniciada. La primera vez que alguien de un dominio verificado inicia sesión, se le añade a tu espacio de trabajo automáticamente. Entre bastidores validamos el token firmado del proveedor de identidad (su firma, el emisor, la audiencia y un nonce por inicio de sesión) antes de fiarnos del correo, de modo que solo una respuesta genuina de tu IdP puede iniciar la sesión de alguien. Y tu IdP solo puede iniciar sesión a direcciones de los dominios que verificaste: una dirección de cualquier otro dominio se rechaza, incluso cuando el token en sí es genuino. Puedes desactivar el SSO en cualquier momento, lo que detiene de inmediato el envío de inicios de sesión a tu IdP (los inicios de sesión con contraseña existentes no se ven afectados). Activar el SSO no desactiva las contraseñas: quienes ya tienen una pueden seguir usándola, hasta que actives Exigir SSO (siguiente sección). Mientras el SSO está activado, los miembros de tu espacio de trabajo cuya dirección pertenece a uno de sus dominios verificados siguen con tu proveedor de identidad. Solo pueden cambiar su correo a otra dirección de esos dominios. Para pasar a alguien a cualquier otra dirección, el propietario o un administrador abre Ajustes → Equipo, hace clic en el menú del miembro y elige Cambiar correo de inicio de sesión (un administrador puede hacerlo con miembros y con puestos de solo lectura; el propietario, con cualquiera): se envía un enlace de confirmación a la dirección nueva, el cambio se produce cuando se hace clic en él (en un plazo de 24 horas), la dirección anterior recibe un aviso y ambos pasos quedan registrados en nuestro registro de auditoría. Y mientras el SSO funciona, «¿Has olvidado la contraseña?» no envía a estos miembros ningún enlace de contraseña, tengan o no una contraseña: reciben un correo que les remite al inicio de sesión único. El propietario del espacio de trabajo es la excepción: conserva «¿Has olvidado la contraseña?», como su vía de regreso si tu proveedor de identidad lo deja fuera (ver Exigir SSO más abajo). Si el plan del espacio de trabajo caduca, se aplican las reglas de las contraseñas temporales descritas más arriba. Mientras el SSO está activado para un dominio, el formulario de registro no crea ninguna cuenta con contraseña para sus direcciones: la dirección recibe un correo con el enlace para iniciar sesión con SSO, y el formulario responde como siempre, de modo que no revela si la dirección tiene una cuenta, y no se envía ningún enlace para confirmar una dirección de ese dominio. Y si alguien abrió una cuenta para una dirección antes de que su titular llegara a confirmarla, la contraseña y las sesiones de esa cuenta se eliminan la primera vez que la persona real inicia sesión con SSO, o con una cuenta de Google que demuestre la dirección (Gmail o Google Workspace), para que nadie pueda preparar de antemano una cuenta con la dirección de un compañero. También se eliminan sus ajustes de doble factor, sus claves API y otros inicios de sesión vinculados, salvo que el inicio de sesión de Google que demuestra la dirección sea el único vinculado: entonces la misma persona los configuró, los conserva y recibe un correo que le avisa de que se eliminó la contraseña. Quien confirmó su dirección antes conserva su contraseña.

Con el SSO activado, las contraseñas y «Continuar con Google» siguen funcionando a su lado. Para que tu proveedor de identidad sea la única vía de acceso, el propietario o un administrador activa Exigir SSO en Ajustes → Inicio de sesión único (SSO). A partir de ese momento, los miembros cuya dirección de correo pertenece a uno de tus dominios verificados solo pueden iniciar sesión con SSO, de modo que las reglas de doble factor de tu IdP y su gestión de bajas se aplican a todos los inicios de sesión. Su contraseña y su inicio de sesión con Google se rechazan con «Tu empresa exige iniciar sesión con SSO», y una sesión que no iniciaron con SSO termina en torno a un minuto después, en su siguiente página o petición. Los miembros con una dirección de otro dominio, como un consultor externo en gmail.com, no se ven afectados, ni tampoco nadie ajeno a tu espacio de trabajo. Quien sea invitado a tu espacio de trabajo con una dirección de tus dominios se une iniciando sesión con SSO. Solo se puede activar cuando el SSO está activado con un dominio verificado, el espacio de trabajo tiene un plan Pro, Agency o Scale activo y alguien ha iniciado sesión a través de tu conexión al menos una vez, lo que demuestra que la configuración funciona. Antes de activarlo, una confirmación enumera a todos los miembros a los que afecta y a todos los que deja al margen, con los recuentos, las invitaciones pendientes a tus dominios y las claves API activas que esos miembros crearon. Activarlo y desactivarlo queda registrado en nuestro registro de auditoría. Desactivar el SSO, o quitar su último dominio verificado, desactiva también Exigir SSO; para volver a activarlo hace falta una confirmación nueva. Mientras el espacio de trabajo no tiene un plan activo, el SSO se pausa y Exigir SSO se pausa con él, así que nadie queda bloqueado. Si tu proveedor de identidad está caído, el propietario del espacio de trabajo aún puede iniciar sesión con su contraseña y la autenticación de dos factores: un código del autenticador o uno de sus códigos de recuperación. Google sigue rechazado. Por eso Exigir SSO solo se puede activar cuando el propietario tiene ambas cosas, por eso el propietario no puede desactivar el doble factor mientras está activado y por eso la propiedad solo puede pasar a alguien que tenga ambas (o cuya dirección no pertenezca a tus dominios). Cada inicio de sesión así queda registrado, y el propietario recibe un correo cada vez. Mientras tu SSO está activado, el propietario siempre puede usar «¿Has olvidado la contraseña?», con o sin Exigir SSO. Nadie puede cambiar por el propietario su correo de inicio de sesión, así que el rol de propietario no se puede secuestrar por esa vía; si el propietario pierde tanto su contraseña como su autenticador, ponte en contacto con nosotros. Las claves API siguen funcionando: pertenecen al espacio de trabajo, no a la sesión de una persona, y las integraciones se romperían si dejaran de funcionar. Revisa las que aparecen en la confirmación en Ajustes → API REST. Los asistentes de IA (MCP) actúan como la persona, así que para estos miembros el conector solo funciona mientras su última conexión se haya hecho después de iniciar sesión con SSO; un asistente conectado desde un inicio de sesión con contraseña o con Google, antes o después de activar Exigir SSO, deja de funcionar hasta que se vuelva a conectar tras iniciar sesión con SSO. Exigir SSO decide cómo inicia sesión la gente; no expulsa a nadie. Una sesión iniciada con SSO sigue funcionando mientras se usa y termina tras 7 días sin actividad, así que para cortar el acceso a alguien de inmediato, elimínalo en Ajustes → Equipo: eso termina su acceso al espacio de trabajo y revoca las claves API que creó. Cambiar tu proveedor de identidad mientras Exigir SSO está activado (un emisor, un ID de cliente o un secreto nuevos) lo mantiene activado: la nueva configuración tiene que funcionar de inmediato y, si no lo hace, el propietario inicia sesión con su contraseña y la autenticación de dos factores para corregirla o desactivar Exigir SSO. El cambio queda registrado en nuestro registro de auditoría. Después de cualquier cambio así, volver a activar Exigir SSO espera a que alguien haya iniciado sesión con SSO a través de la nueva configuración. Eliminar la conexión SSO desactiva Exigir SSO, y eso también queda registrado.

Un intento fallido vuelve a la página de inicio de sesión con un mensaje breve. Qué significa cada uno: «no está disponible para ese dominio de correo»: el dominio no está verificado, el SSO no está activado para él o el espacio de trabajo no tiene un plan Pro, Agency o Scale activo. El mensaje es el mismo en cada caso, de modo que la página de inicio de sesión no revela a nadie el plan de un espacio de trabajo; mientras tanto, entra con tu contraseña o con Google (¿aún sin contraseña? usa «¿Has olvidado la contraseña?» para crear una). «No hemos podido conectar con el proveedor de identidad de tu empresa»: la URL de emisor en Ajustes → Inicio de sesión único (SSO) es incorrecta o el IdP está caído. «No hemos podido verificar la respuesta» o «no ha devuelto un token de inicio de sesión»: el ID de cliente o el secreto de cliente no coincide con la aplicación del IdP. «ha caducado o se abrió en otro navegador»: el intento tardó más de diez minutos, o las cookies están bloqueadas; empieza de nuevo. «no ha verificado tu correo»: el IdP no avala ese buzón, así que no iniciamos sesión con él. «cuyo dominio no está verificado para el inicio de sesión único de tu espacio de trabajo»: tu IdP devolvió una dirección de un dominio que no has verificado (un dominio alias o un subdominio, por ejemplo); verifica también ese dominio, o haz que el IdP envíe la dirección de tu dominio verificado. «El inicio de sesión único de tu empresa vuelve a estar activo»: la contraseña que usaste se creó mientras el SSO no estaba disponible y, ahora que vuelve a funcionar, se ha eliminado: haz clic en «Continuar con inicio de sesión único (SSO)». «Tu empresa exige iniciar sesión con SSO»: tu espacio de trabajo tiene Exigir SSO activado, así que tu contraseña y Google no te permiten entrar: haz clic en «Continuar con inicio de sesión único (SSO)». Un error mostrado por el propio IdP (por ejemplo «redirect_uri_mismatch») significa que hay que corregir la aplicación registrada allí, no CrunchJunkie.