Resumen: Claude utiliza el correo electrónico como identificador principal para hacer coincidir los inicios de sesión SSO con los asientos aprovisionados. En Okta, el aprovisionamiento SCIM y SSO se configuran en secciones separadas de la aplicación y pueden extraer el correo electrónico de diferentes campos de perfil de usuario de Okta. Esta guía explica cómo identificar y corregir la discrepancia.

Síntomas

Los usuarios pueden experimentar uno o más de los siguientes al intentar acceder a Claude for Enterprise a través de SSO:

"La creación de cuenta está bloqueada" — El usuario se autentica a través de SSO pero Claude no puede encontrar una cuenta aprovisionada coincidente.
Aterrizaje en una cuenta personal gratuita — Si la creación de organización no está restringida, el usuario omite la organización empresarial.
"Por favor confirme su correo electrónico" discrepancia — La devolución de llamada SSO muestra un correo electrónico diferente al que el usuario ingresó en el inicio de sesión.
Fallo de autenticación de Claude Code — La CLI de Claude Code muestra un error de discrepancia de correo electrónico.

Cómo sucede esto

Los perfiles de usuario de Okta contienen múltiples campos que representan la identidad. El aprovisionamiento SCIM (bajo Provisioning → To App) y SSO SAML/OIDC (bajo Sign On) se configuran de forma independiente:

Atributo de Okta	Valor típico	Comúnmente utilizado por
`user.login`	`testuser1` o `[email protected]`	Mapeo predeterminado de userName de SCIM; a veces NameID
`user.email`	`[email protected]`	Reclamación de correo electrónico SAML/OIDC (recomendado)
`appuser.email`	Anulación a nivel de aplicación del correo electrónico del usuario	Mapeo de atributos personalizado a nivel de aplicación

Una discrepancia común: SCIM utiliza user.login mientras que SAML envía user.email. Claude requiere una coincidencia exacta de cadena.

Confusión común: Los mapeos de atributos SCIM de Okta y las declaraciones de atributos SAML se encuentran en dos pestañas diferentes — Provisioning → To App para SCIM, y Sign On para SSO. Debe verificar ambos.

Pasos de diagnóstico

Paso 1 — Confirmar la discrepancia

Verificar el correo electrónico SCIM: En la consola de administración de Okta, vaya a Applications → [Claude App] → Provisioning → To App → Attribute Mappings. Encuentre la fila para email (o userName si eso se asigna al correo electrónico en el lado de Claude). La columna Value muestra la expresión o campo de Okta que se envía.
Verificar el correo electrónico SSO (SAML): Vaya a Applications → [Claude App] → Sign On → SAML Settings → Edit → Attribute Statements. Encuentre el atributo denominado email. La columna Value muestra qué campo de Okta se afirma en el inicio de sesión.
Verificar el correo electrónico SSO (OIDC): Vaya a Applications → [Claude App] → Sign On → OpenID Connect ID Token y verifique la sección Claims para la reclamación de correo electrónico.
Si los valores SCIM y SSO hacen referencia a diferentes campos de Okta, ha confirmado la discrepancia.

Paso 2 — Identificar el alcance del problema

Determine si esto afecta a un usuario o es un problema sistémico:

Si la mayoría o todos los usuarios aprovisionados comparten la misma discrepancia de formato de correo electrónico, este es un problema de mapeo de atributos sistémico que afecta a todo su directorio. La solución está en el mapeo de atributos SCIM de su IdP.
Si solo uno o dos usuarios se ven afectados mientras que otros funcionan bien, el problema probablemente sea específico de esas cuentas de usuario. Verifique su perfil de usuario directamente.

Paso 3 — Verificar los perfiles de usuario de Okta directamente

Para usuarios individuales afectados, verifique sus valores de campo reales:

Vaya a Directory → People → [User] → Profile.
Compare los valores de los campos Login y Email. Si difieren, cualquier mapeo que use Login vs. Email producirá una discrepancia.

Resolución

Alinear ambos mapeos al mismo campo de Okta

La solución más segura es usar user.email tanto para SCIM como para SSO, ya que este campo contiene la dirección de correo electrónico canónica en Okta.

Actualizar mapeo SCIM: En Provisioning → To App → Attribute Mappings, cambie la fuente de email (o userName) a user.email.
Actualizar reclamación SSO (SAML): En Sign On → SAML Settings → Attribute Statements, cambie el valor del atributo email a user.email.
Actualizar reclamación SSO (OIDC): En Sign On → OpenID Connect ID Token → Claims, actualice la reclamación de correo electrónico para asignarla a user.email.
Haga clic en Save.

Forzar una resincronización completa

Crítico — Se requiere sincronización completa: Una sincronización incremental no actualizará los usuarios existentes después de cambiar un mapeo de atributos. Debe activar un reinicio completo del ciclo de aprovisionamiento.

En Provisioning → To App, haga clic en Force Sync para activar una reevaluación completa de todos los usuarios asignados.
Alternativamente, para usuarios específicos: Provisioning → Push Users → seleccione usuarios afectados → Push Now.
Verifique el Registro del Sistema de Okta (Reports → System Log) para cualquier error de aprovisionamiento.
Verifique que los valores de correo electrónico actualizados aparezcan en los registros de aprovisionamiento antes de pedir a los usuarios que reintentar el inicio de sesión.

Limpieza posterior a la corrección

Después de corregir el mapeo de atributos y completar la sincronización completa, es posible que necesite limpieza adicional según su situación:

Cuentas gratuitas no autorizadas: Si la creación de organización no estaba restringida antes de la corrección, algunos usuarios pueden haber creado inadvertidamente cuentas personales gratuitas de Claude. Póngase en contacto con Anthropic Support para que se eliminen.
Cuentas fantasma (asientos con correo electrónico incorrecto): Las cuentas aprovisionadas originalmente (con el correo electrónico incorrecto) pueden seguir existiendo en su organización empresarial, ocupando asientos que nunca se pueden usar. Póngase en contacto con Anthropic Support para desaprovisionar estas cuentas fantasma.
Disponibilidad de asientos: Si las cuentas fantasma ocupan todos los asientos contratados, los nuevos inicios de sesión fallarán con un error sin asientos incluso después de que se corrija el mapeo. Póngase en contacto con soporte si está experimentando esto.
Readición de usuarios afectados: Después de que se eliminen las cuentas fantasma, es posible que los usuarios con el correo electrónico corregido necesiten ser reinvitados o reaprovisionados.

Prevenir ocurrencias futuras: Habilite "Restrict organization creation" en la configuración de su empresa. Esto evita que los usuarios que aún no están aprovisionados creen accidentalmente cuentas personales gratuitas.

Verificación

Después de completar la corrección y cualquier limpieza, verifique lo siguiente:

Verifique una muestra de usuarios aprovisionados — confirme que su correo electrónico en el registro de aprovisionamiento de su IdP coincida con el formato de correo electrónico que SSO envía.
Pida a un usuario afectado que borre las cookies del navegador para claude.ai, luego inicie sesión a través de SSO. Deberían aterrizar directamente en el espacio de trabajo empresarial sin ningún error.
Confirme que los usuarios no están creando accidentalmente cuentas gratuitas — si la creación de organización está restringida, los usuarios bloqueados verán un error claro en lugar de aterrizar en una cuenta personal.
Si Claude Code se vio afectado, pida al usuario que vuelva a ejecutar claude auth login --enterprise y confirme que el correo electrónico coincide con su asiento empresarial.

Errores comunes

Error	Solución
El administrador actualiza las reclamaciones SAML pero olvida los mapeos de atributos SCIM (o viceversa)	Ambos deben actualizarse. Los mapeos SCIM están bajo Provisioning → To App; las reclamaciones SAML están bajo Sign On → SAML Settings.
`user.login` contiene el nombre de usuario (no un correo electrónico) para algunos usuarios	Cambie ambos a `user.email` y verifique que los campos de correo electrónico estén completos para todos los usuarios.
La sincronización incremental se ejecuta pero los correos electrónicos no se actualizan	Se requiere Force Sync o Push Users después de un cambio de mapeo de atributos.
El atributo de perfil a nivel de aplicación (`appuser.email`) difiere del perfil de usuario (`user.email`)	Verifique si los mapeos de atributos a nivel de aplicación están anulando los valores del perfil de usuario.
Los correos electrónicos se actualizaron pero el usuario aún no puede iniciar sesión	Busque organizaciones gratuitas no autorizadas o cuentas fantasma. Borre las cookies del navegador e intente de nuevo. Póngase en contacto con Anthropic Support si el problema persiste.
Las aplicaciones OIDC y SAML son aplicaciones Okta separadas para Claude	Algunas organizaciones configuran ambas. Asegúrese de que la alineación de atributos se verifique en ambas aplicaciones.

Cuándo contactar a Anthropic Support

Los atributos SCIM y SSO parecen idénticos pero los usuarios aún no pueden acceder a sus asientos.
Necesita confirmar qué correo electrónico registró Claude durante el aprovisionamiento SCIM para usuarios específicos.
Necesita ayuda para limpiar cuentas fantasma u organizaciones gratuitas no autorizadas.
Los usuarios están experimentando un error sin asientos a pesar de que su contrato tiene asientos disponibles.

Póngase en contacto con [email protected] con el dominio de su organización, la dirección de correo electrónico del usuario afectado y capturas de pantalla de sus mapeos de atributos.

Desajuste de correo electrónico SSO/SCIM — Okta