Resumo: Claude usa email como o identificador principal para corresponder logins SSO a assentos provisionados. No Okta, o provisionamento SCIM e SSO são configurados em seções separadas do aplicativo e podem extrair email de diferentes campos de perfil de usuário do Okta. Este guia explica como identificar e corrigir a incompatibilidade.

Sintomas

Os usuários podem experimentar um ou mais dos seguintes ao tentar acessar Claude for Enterprise via SSO:

"Criação de conta bloqueada" — O usuário se autentica via SSO, mas Claude não consegue encontrar uma conta provisionada correspondente.
Aterrissagem em uma conta pessoal gratuita — Se a criação de organização não for restrita, o usuário ignora a organização empresarial.
Incompatibilidade em "Por favor, confirme seu email" — O retorno de chamada SSO mostra um email diferente do que o usuário inseriu no login.
Falha de autenticação do Claude Code — O CLI do Claude Code mostra um erro de incompatibilidade de email.

Como isso acontece

Os perfis de usuário do Okta contêm múltiplos campos que representam identidade. O provisionamento SCIM (em Provisioning → To App) e SSO SAML/OIDC (em Sign On) são configurados independentemente:

Atributo Okta	Valor Típico	Comumente Usado Por
`user.login`	`testuser1` ou `[email protected]`	Mapeamento padrão de userName SCIM; às vezes NameID
`user.email`	`[email protected]`	Declaração de email SAML/OIDC (recomendado)
`appuser.email`	Substituição de nível de aplicativo do email do usuário	Mapeamento de atributo personalizado de nível de aplicativo

Uma incompatibilidade comum: SCIM usa user.login enquanto SAML envia user.email. Claude requer uma correspondência exata de string.

Confusão comum: Os mapeamentos de atributos SCIM do Okta e as declarações de atributos SAML vivem em duas abas diferentes — Provisioning → To App para SCIM e Sign On para SSO. Você deve verificar ambas.

Etapas de diagnóstico

Etapa 1 — Confirme a incompatibilidade

Verifique o email SCIM: No console de administração do Okta, vá para Applications → [Claude App] → Provisioning → To App → Attribute Mappings. Encontre a linha para email (ou userName se isso mapear para email no lado do Claude). A coluna Value mostra a expressão ou campo do Okta sendo enviado.
Verifique o email SSO (SAML): Vá para Applications → [Claude App] → Sign On → SAML Settings → Edit → Attribute Statements. Encontre o atributo chamado email. A coluna Value mostra qual campo do Okta é afirmado no login.
Verifique o email SSO (OIDC): Vá para Applications → [Claude App] → Sign On → OpenID Connect ID Token e verifique a seção Claims para a declaração de email.
Se os valores SCIM e SSO fazem referência a campos diferentes do Okta, você confirmou a incompatibilidade.

Etapa 2 — Identifique o escopo do problema

Determine se isso afeta um usuário ou é um problema sistêmico:

Se a maioria ou todos os usuários provisionados compartilham a mesma incompatibilidade de formato de email, este é um problema de mapeamento de atributo sistêmico afetando todo o seu diretório. A correção está no mapeamento de atributo SCIM do seu IdP.
Se apenas um ou dois usuários são afetados enquanto outros funcionam bem, o problema é provavelmente específico dessas contas de usuário. Verifique seu perfil de usuário diretamente.

Etapa 3 — Verifique os perfis de usuário do Okta diretamente

Para usuários individuais afetados, verifique seus valores de campo reais:

Vá para Directory → People → [User] → Profile.
Compare os valores dos campos Login e Email. Se forem diferentes, qualquer mapeamento usando Login vs. Email produzirá uma incompatibilidade.

Resolução

Alinhe ambos os mapeamentos ao mesmo campo do Okta

A correção mais segura é usar user.email para SCIM e SSO, pois este campo contém o endereço de email canônico no Okta.

Atualize o mapeamento SCIM: Em Provisioning → To App → Attribute Mappings, altere a fonte email (ou userName) para user.email.
Atualize a declaração SSO (SAML): Em Sign On → SAML Settings → Attribute Statements, altere o valor do atributo email para user.email.
Atualize a declaração SSO (OIDC): Em Sign On → OpenID Connect ID Token → Claims, atualize a declaração de email para mapear para user.email.
Clique em Save.

Force uma ressincronização completa

Crítico — Ressincronização completa necessária: Uma sincronização incremental não atualizará usuários existentes após você alterar um mapeamento de atributo. Você deve disparar um reinício completo do ciclo de provisionamento.

Em Provisioning → To App, clique em Force Sync para disparar uma reavaliação completa de todos os usuários atribuídos.
Alternativamente, para usuários específicos: Provisioning → Push Users → selecione usuários afetados → Push Now.
Verifique o System Log do Okta (Reports → System Log) para qualquer erro de provisionamento.
Verifique se os valores de email atualizados aparecem nos logs de provisionamento antes de pedir aos usuários para tentar fazer login novamente.

Limpeza pós-correção

Após corrigir o mapeamento de atributo e concluir a sincronização completa, você pode precisar de limpeza adicional dependendo da sua situação:

Contas gratuitas não autorizadas: Se a criação de organização não foi restrita antes da correção, alguns usuários podem ter criado inadvertidamente contas Claude pessoais gratuitas. Entre em contato com Anthropic Support para removê-las.
Contas fantasma (assentos com email incorreto): As contas originalmente provisionadas (com o email incorreto) podem ainda existir em sua organização empresarial, ocupando assentos que nunca podem ser usados. Entre em contato com Anthropic Support para desprovisionar essas contas fantasma.
Disponibilidade de assentos: Se contas fantasma estão ocupando todos os assentos contratados, novos logins falharão com um erro de falta de assentos mesmo após o mapeamento ser corrigido. Entre em contato com o suporte se você estiver enfrentando isso.
Re-adição de usuários afetados: Após as contas fantasma serem removidas, usuários com o email corrigido podem precisar ser re-convidados ou reprovistos.

Previna ocorrências futuras: Ative "Restrict organization creation" nas configurações da sua empresa. Isso impede que usuários que ainda não foram provisionados criem acidentalmente contas pessoais gratuitas.

Verificação

Após concluir a correção e qualquer limpeza, verifique o seguinte:

Verifique uma amostra de usuários provisionados — confirme que seu email no log de provisionamento do seu IdP corresponde ao formato de email que SSO envia.
Peça a um usuário afetado para limpar cookies do navegador para claude.ai, depois faça login via SSO. Ele deve aterrissar diretamente no espaço de trabalho empresarial sem nenhum erro.
Confirme que os usuários não estão criando acidentalmente contas gratuitas — se a criação de organização for restrita, usuários bloqueados verão um erro claro em vez de aterrissar em uma conta pessoal.
Se Claude Code foi afetado, peça ao usuário para executar novamente claude auth login --enterprise e confirme que o email corresponde ao seu assento empresarial.

Armadilhas comuns

Armadilha	Solução
Admin atualiza declarações SAML mas esquece mapeamentos de atributo SCIM (ou vice-versa)	Ambos devem ser atualizados. Mapeamentos SCIM estão em Provisioning → To App; declarações SAML estão em Sign On → SAML Settings.
`user.login` contém o nome de usuário (não um email) para alguns usuários	Mude ambos para `user.email` e verifique se os campos de email estão preenchidos para todos os usuários.
Sincronização incremental é executada mas emails não são atualizados	Force Sync ou Push Users é necessário após uma alteração de mapeamento de atributo.
Atributo de perfil de nível de aplicativo (`appuser.email`) difere do perfil de usuário (`user.email`)	Verifique se mapeamentos de atributo de nível de aplicativo estão substituindo valores de perfil de usuário.
Emails atualizados mas usuário ainda não consegue fazer login	Procure por orgs gratuitas não autorizadas ou contas fantasma. Limpe cookies do navegador e tente novamente. Entre em contato com Anthropic Support se o problema persistir.
Aplicativos OIDC e SAML são aplicativos Okta separados para Claude	Algumas organizações configuram ambos. Certifique-se de que o alinhamento de atributo seja verificado em ambos os aplicativos.

Quando entrar em contato com Anthropic Support

Atributos SCIM e SSO parecem idênticos mas usuários ainda não conseguem acessar seus assentos.
Você precisa confirmar qual email Claude registrou durante o provisionamento SCIM para usuários específicos.
Você precisa de ajuda para limpar contas fantasma ou orgs gratuitas não autorizadas.
Usuários estão recebendo um erro de falta de assentos apesar de seu contrato ter assentos disponíveis.

Entre em contato com [email protected] com o domínio da sua organização, o endereço de email do usuário afetado e capturas de tela de seus mapeamentos de atributo.

Incompatibilidade de Email SSO/SCIM — Okta