Résumé : Claude utilise l'adresse e-mail comme identifiant principal pour faire correspondre les connexions SSO aux sièges provisionnés. Dans Okta, le provisionnement SCIM et l'authentification unique sont configurés dans des sections distinctes de l'application et peuvent extraire l'e-mail de différents champs de profil utilisateur Okta. Ce guide explique comment identifier et corriger l'inadéquation.

Symptômes

Les utilisateurs peuvent rencontrer un ou plusieurs des problèmes suivants lorsqu'ils tentent d'accéder à Claude for Enterprise via SSO :

« La création de compte est bloquée » — L'utilisateur s'authentifie via SSO mais Claude ne peut pas trouver un compte provisionné correspondant.
Accès à un compte personnel gratuit — Si la création d'organisation n'est pas restreinte, l'utilisateur contourne l'organisation d'entreprise.
« Veuillez confirmer votre e-mail » inadéquation — Le rappel SSO affiche une adresse e-mail différente de celle que l'utilisateur a saisie lors de la connexion.
Échec de l'authentification Claude Code — L'interface de ligne de commande Claude Code affiche une erreur d'inadéquation d'e-mail.

Comment cela se produit

Les profils utilisateur Okta contiennent plusieurs champs qui représentent l'identité. Le provisionnement SCIM (sous Provisioning → To App) et l'authentification unique SAML/OIDC (sous Sign On) sont configurés indépendamment :

Attribut Okta	Valeur typique	Couramment utilisé par
`user.login`	`testuser1` ou `[email protected]`	Mappage userName SCIM par défaut ; parfois NameID
`user.email`	`[email protected]`	Revendication d'e-mail SAML/OIDC (recommandé)
`appuser.email`	Remplacement au niveau de l'application de l'e-mail utilisateur	Mappage d'attribut personnalisé au niveau de l'application

Une inadéquation courante : SCIM utilise user.login tandis que SAML envoie user.email. Claude nécessite une correspondance exacte de chaîne.

Confusion courante : Les mappages d'attributs SCIM d'Okta et les déclarations d'attributs SAML se trouvent dans deux onglets différents — Provisioning → To App pour SCIM, et Sign On pour SSO. Vous devez vérifier les deux.

Étapes de diagnostic

Étape 1 — Confirmer l'inadéquation

Vérifiez l'e-mail SCIM : Dans la console d'administration Okta, accédez à Applications → [Claude App] → Provisioning → To App → Attribute Mappings. Trouvez la ligne pour email (ou userName si cela correspond à l'e-mail du côté de Claude). La colonne Value affiche l'expression ou le champ Okta envoyé.
Vérifiez l'e-mail SSO (SAML) : Accédez à Applications → [Claude App] → Sign On → SAML Settings → Edit → Attribute Statements. Trouvez l'attribut nommé email. La colonne Value affiche le champ Okta qui est affirmé lors de la connexion.
Vérifiez l'e-mail SSO (OIDC) : Accédez à Applications → [Claude App] → Sign On → OpenID Connect ID Token et vérifiez la section Claims pour la revendication d'e-mail.
Si les valeurs SCIM et SSO font référence à des champs Okta différents, vous avez confirmé l'inadéquation.

Étape 2 — Identifier l'étendue du problème

Déterminez s'il s'agit d'un utilisateur affecté ou d'un problème systémique :

Si la plupart ou tous les utilisateurs provisionnés partagent la même inadéquation de format d'e-mail, il s'agit d'un problème de mappage d'attribut systémique affectant tout votre répertoire. La correction se trouve dans le mappage d'attribut SCIM de votre IdP.
Si seulement un ou deux utilisateurs sont affectés tandis que d'autres fonctionnent correctement, le problème est probablement spécifique à ces comptes utilisateur. Vérifiez leur profil utilisateur directement.

Étape 3 — Vérifier les profils utilisateur Okta directement

Pour les utilisateurs affectés individuels, vérifiez leurs valeurs de champ réelles :

Accédez à Directory → People → [User] → Profile.
Comparez les valeurs des champs Login et Email. S'ils diffèrent, tout mappage utilisant Login par rapport à Email produira une inadéquation.

Résolution

Aligner les deux mappages sur le même champ Okta

La correction la plus sûre est d'utiliser user.email pour SCIM et SSO, car ce champ contient l'adresse e-mail canonique dans Okta.

Mettre à jour le mappage SCIM : Dans Provisioning → To App → Attribute Mappings, modifiez la source email (ou userName) en user.email.
Mettre à jour la revendication SSO (SAML) : Dans Sign On → SAML Settings → Attribute Statements, modifiez la valeur de l'attribut email en user.email.
Mettre à jour la revendication SSO (OIDC) : Dans Sign On → OpenID Connect ID Token → Claims, mettez à jour la revendication d'e-mail pour la mapper à user.email.
Cliquez sur Save.

Forcer une resynchronisation complète

Critique — Resynchronisation complète requise : Une synchronisation incrémentale ne mettra pas à jour les utilisateurs existants après avoir modifié un mappage d'attribut. Vous devez déclencher un redémarrage complet du cycle de provisionnement.

Dans Provisioning → To App, cliquez sur Force Sync pour déclencher une réévaluation complète de tous les utilisateurs assignés.
Alternativement, pour les utilisateurs ciblés : Provisioning → Push Users → sélectionnez les utilisateurs affectés → Push Now.
Vérifiez le journal système Okta (Reports → System Log) pour les erreurs de provisionnement.
Vérifiez que les valeurs d'e-mail mises à jour apparaissent dans les journaux de provisionnement avant de demander aux utilisateurs de réessayer la connexion.

Nettoyage après correction

Après avoir corrigé le mappage d'attribut et complété la synchronisation complète, vous devrez peut-être effectuer un nettoyage supplémentaire selon votre situation :

Comptes gratuits non autorisés : Si la création d'organisation n'était pas restreinte avant la correction, certains utilisateurs ont peut-être créé par inadvertance des comptes Claude personnels gratuits. Contactez Anthropic Support pour les faire supprimer.
Comptes fantômes (sièges avec mauvais e-mail) : Les comptes provisionnés à l'origine (avec l'e-mail incorrect) peuvent toujours exister dans votre organisation d'entreprise, occupant des sièges qui ne peuvent jamais être utilisés. Contactez Anthropic Support pour déprovisionner ces comptes fantômes.
Disponibilité des sièges : Si les comptes fantômes occupent tous les sièges contractés, les nouvelles connexions échoueront avec une erreur de manque de sièges même après la correction du mappage. Contactez le support si vous rencontrez ce problème.
Réajout des utilisateurs affectés : Après la suppression des comptes fantômes, les utilisateurs avec l'e-mail corrigé devront peut-être être réinvités ou reprovisionnés.

Prévenir les occurrences futures : Activez « Restrict organization creation » dans vos paramètres d'entreprise. Cela empêche les utilisateurs qui ne sont pas encore provisionnés de créer accidentellement des comptes personnels gratuits.

Vérification

Après avoir complété la correction et tout nettoyage, vérifiez les éléments suivants :

Vérifiez un échantillon d'utilisateurs provisionnés — confirmez que leur e-mail dans le journal de provisionnement de votre IdP correspond au format d'e-mail que SSO envoie.
Demandez à un utilisateur affecté d'effacer les cookies du navigateur pour claude.ai, puis de se connecter via SSO. Il devrait accéder directement à l'espace de travail d'entreprise sans aucune erreur.
Confirmez que les utilisateurs ne créent pas accidentellement de comptes gratuits — si la création d'organisation est restreinte, les utilisateurs bloqués verront une erreur claire plutôt que d'accéder à un compte personnel.
Si Claude Code a été affecté, demandez à l'utilisateur de réexécuter claude auth login --enterprise et confirmez que l'e-mail correspond à son siège d'entreprise.

Pièges courants

Piège	Solution
L'administrateur met à jour les revendications SAML mais oublie les mappages d'attributs SCIM (ou vice versa)	Les deux doivent être mis à jour. Les mappages SCIM se trouvent sous Provisioning → To App ; les revendications SAML se trouvent sous Sign On → SAML Settings.
`user.login` contient le nom d'utilisateur (pas un e-mail) pour certains utilisateurs	Basculez les deux vers `user.email` et vérifiez que les champs d'e-mail sont remplis pour tous les utilisateurs.
La synchronisation incrémentale s'exécute mais les e-mails ne se mettent pas à jour	Force Sync ou Push Users est requis après une modification du mappage d'attribut.
L'attribut de profil au niveau de l'application (`appuser.email`) diffère du profil utilisateur (`user.email`)	Vérifiez si les mappages d'attributs au niveau de l'application remplacent les valeurs du profil utilisateur.
Les e-mails sont mis à jour mais l'utilisateur ne peut toujours pas se connecter	Recherchez les organisations gratuites non autorisées ou les comptes fantômes. Effacez les cookies du navigateur et réessayez. Contactez Anthropic Support si le problème persiste.
Les applications OIDC et SAML sont des applications Okta distinctes pour Claude	Certaines organisations configurent les deux. Assurez-vous que l'alignement des attributs est vérifié dans les deux applications.

Quand contacter Anthropic Support

Les attributs SCIM et SSO semblent identiques mais les utilisateurs ne peuvent toujours pas accéder à leurs sièges.
Vous devez confirmer quel e-mail Claude a enregistré lors du provisionnement SCIM pour des utilisateurs spécifiques.
Vous avez besoin d'aide pour nettoyer les comptes fantômes ou les organisations gratuites non autorisées.
Les utilisateurs rencontrent une erreur de manque de sièges malgré votre contrat ayant des sièges disponibles.

Contactez [email protected] avec le domaine de votre organisation, l'adresse e-mail de l'utilisateur affecté et des captures d'écran de vos mappages d'attributs.

Décalage d'e-mail SSO/SCIM — Okta