L’authentification unique permet aux personnes de vos domaines vérifiés de se connecter à 50heads avec le compte qu’elles utilisent déjà au travail. La page de connexion de leur entreprise (votre fournisseur d’identité, comme Okta, Microsoft Entra ID ou Google Workspace) vérifie qui elles sont, puis les renvoie sur 50heads, connectées. Elle fonctionne avec OpenID Connect ou SAML 2.0 : vous choisissez celui qu’utilise l’application de votre fournisseur d’identité.

Nous déployons l’authentification unique progressivement auprès des organisations. Si vous ne voyez pas Authentification unique dans Réglages, puis Organisation, elle n’est pas encore activée pour votre organisation. Contactez-nous si vous la souhaitez.

Avant de commencer

  • Votre organisation doit avoir au moins un domaine vérifié. Seules les personnes dont l’adresse e-mail est sur un domaine vérifié peuvent utiliser l’authentification unique. Voir Votre organisation et ses domaines.
  • Vous devez être propriétaire ou administrateur d’une des équipes de l’organisation, connecté sur le site.
  • Votre propre adresse e-mail doit être sur le domaine vérifié, avec un compte chez votre fournisseur d’identité. Vous en aurez besoin pour le test de connexion.

OpenID Connect ou SAML

Les deux font le même travail, et les personnes qui se connectent ne voient aucune différence. Choisissez celui qui convient à votre fournisseur d’identité :

  • OpenID Connect demande un ID client et un secret client à votre fournisseur d’identité. La plupart des installations récentes l’utilisent.
  • SAML 2.0 ne demande aucun secret. Vous donnez à votre fournisseur d’identité trois valeurs de 50heads, et il vous rend un fichier ou une URL de métadonnées. Choisissez-le si votre équipe informatique préfère les applications SAML ou en utilise déjà.

Dans Réglages, puis Organisation, choisissez OpenID Connect ou SAML 2.0 en haut de Votre fournisseur d’identité. Vous pouvez changer plus tard. Un changement compte comme une modification des réglages du fournisseur : l’authentification unique reste désactivée jusqu’à ce qu’un nouveau test réussisse. Après un changement, les personnes déjà connectées auparavant confirment leur compte une fois de plus avec un code à 6 chiffres reçu par e-mail.

Avec OpenID Connect : ce qu’il faut déclarer

Créez une application web (parfois appelée client) chez votre fournisseur d’identité, avec ces réglages. La page des réglages affiche l’URI de redirection exacte à copier.

Réglage Valeur
Type Application web, OpenID Connect, code d’autorisation
URI de redirection https://api.50heads.com/v1/auth/sso/callback
Scopes openid email profile
PKCE S256 (50heads l’envoie toujours)

Depuis l’application, copiez trois éléments dans 50heads : l’URL de l’émetteur (issuer), l’ID client et le secret client.

Okta (OpenID Connect)

  1. Dans l’Admin Console, allez dans Applications, puis Create App Integration. Choisissez OIDC – OpenID Connect et Web Application.
  2. N’utilisez que le type Authorization Code, et ajoutez l’URI de redirection comme URI de redirection de connexion.
  3. Attribuez l’application aux personnes ou groupes qui peuvent utiliser 50heads.
  4. Copiez le Client ID et le Client secret dans l’onglet General.
  5. L’URL de l’émetteur est votre domaine Okta, comme https://example.okta.com, ou un serveur d’autorisation personnalisé, comme https://example.okta.com/oauth2/default.

Microsoft Entra ID (OpenID Connect)

  1. Dans le centre d’administration Entra, allez dans Inscriptions d’applications, puis Nouvelle inscription. Choisissez un seul locataire, et ajoutez l’URI de redirection avec la plateforme Web.
  2. Dans Certificats et secrets, créez un secret client et copiez sa Valeur (pas son ID). Notez sa date d’expiration.
  3. Copiez l’ID d’application (client) et l’ID de l’annuaire (locataire).
  4. L’URL de l’émetteur est https://login.microsoftonline.com/<ID du locataire>/v2.0. N’utilisez pas les adresses common ou organizations.
  5. Dans Configuration des jetons, ajoutez les revendications facultatives email et xms_edov. Entra n’indique pas autrement qu’une adresse e-mail est vérifiée : sans xms_edov, chaque connexion est refusée.

Google Workspace (OpenID Connect)

  1. Dans la console Google Cloud, dans un projet appartenant à votre organisation Workspace, réglez l’écran de consentement OAuth sur Interne.
  2. Créez un ID client OAuth de type Application Web, avec l’URI de redirection comme URI de redirection autorisée.
  3. Copiez le Client ID et le Client secret.
  4. L’URL de l’émetteur est https://accounts.google.com. Seuls les comptes de votre Workspace peuvent se connecter ainsi, jamais les comptes Gmail personnels.

Avec SAML : ce qu’il faut déclarer

Créez une application SAML pour 50heads chez votre fournisseur d’identité. La page des réglages affiche les valeurs exactes à copier, et vous pouvez les télécharger sous forme de fichier de métadonnées avec Télécharger nos métadonnées.

Réglage Valeur
URL d’authentification unique, URL de réponse ou URL du service consommateur d’assertions (ACS) https://api.50heads.com/v1/auth/sso/saml/acs
ID d’entité, audience ou identifiant https://api.50heads.com/v1/auth/sso/saml/metadata/<ID de l’organisation> (la page des réglages affiche le vôtre)
Format du Name ID Adresse e-mail
Signature Signez l’assertion (ou toute la réponse) en RSA-SHA256. SHA-1 est refusé
Requêtes signées Désactivées. 50heads ne signe pas ses requêtes
Chiffrement des assertions Désactivé. 50heads n’accepte pas les assertions chiffrées

Le Name ID doit être l’adresse e-mail professionnelle de la personne. Si votre fournisseur d’identité envoie un autre Name ID, envoyez aussi un attribut email avec l’adresse.

Depuis l’application, donnez à 50heads ses métadonnées : une URL (nous la lisons à l’enregistrement, et uniquement en https) ou le fichier de métadonnées. Les métadonnées indiquent votre fournisseur d’identité, son URL de connexion et son certificat de signature.

Okta (SAML)

  1. Dans l’Admin Console, allez dans Applications, puis Create App Integration, et choisissez SAML 2.0.
  2. Réglez Single sign-on URL sur l’URL ACS et Audience URI (SP Entity ID) sur l’ID d’entité. Laissez Use this for Recipient URL and Destination URL coché.
  3. Réglez Name ID format sur EmailAddress et Application username sur Email.
  4. Facultatif : dans Attribute Statements, ajoutez email avec la valeur user.email.
  5. Attribuez l’application aux personnes ou groupes qui peuvent utiliser 50heads.
  6. Dans l’onglet Sign On, copiez la Metadata URL dans 50heads.

Microsoft Entra ID (SAML)

  1. Dans le centre d’administration Entra, allez dans Applications d’entreprise, puis Nouvelle application, puis Créer votre propre application. Choisissez Intégrer une autre application que vous ne trouvez pas dans la galerie (non-galerie).
  2. Dans Authentification unique, choisissez SAML. Dans Configuration SAML de base, réglez Identificateur (ID d’entité) sur l’ID d’entité et URL de réponse (URL Assertion Consumer Service) sur l’URL ACS. Laissez URL de connexion et État de relais vides.
  3. Dans Attributs et revendications, réglez l’identificateur d’utilisateur unique (Name ID) sur l’adresse e-mail de l’utilisateur, au format Adresse e-mail. Entra envoie déjà l’adresse dans la revendication http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.
  4. Dans Certificats SAML, laissez l’option de signature sur Signer l’assertion SAML et l’algorithme sur SHA-256. Copiez l’URL des métadonnées de fédération d’application dans 50heads.
  5. Dans Utilisateurs et groupes, attribuez l’application aux personnes ou groupes qui peuvent utiliser 50heads.

Google Workspace (SAML)

  1. Dans la console d’administration Google, allez dans Applications, puis Applications Web et mobiles, puis Ajouter une application, puis Ajouter une application SAML personnalisée.
  2. Sur la page Informations sur le fournisseur d’identité Google, choisissez Télécharger les métadonnées. Vous donnerez ce fichier à 50heads.
  3. Réglez URL ACS sur l’URL ACS et ID d’entité sur l’ID d’entité. Laissez Réponse signée désactivée : Google signe l’assertion, et c’est ce que vérifie 50heads.
  4. Réglez Format de l’ID de nom sur EMAIL et ID de nom sur Informations de base > Adresse e-mail principale.
  5. Activez l’application pour les personnes ou unités organisationnelles qui peuvent utiliser 50heads.
  6. Dans 50heads, collez le contenu du fichier de métadonnées, ou choisissez le fichier.

La configurer dans 50heads

  1. Ouvrez Réglages, puis Organisation, et choisissez Confirmer que c’est vous si on vous le demande. Chaque modification demande cette vérification, valable 10 minutes.
  2. Dans Authentification unique, choisissez le protocole. Pour OpenID Connect, saisissez l’URL de l’émetteur, l’ID client et le secret client. Nous stockons le secret chiffré et n’en montrons que les quatre derniers caractères. Pour SAML, saisissez l’URL des métadonnées, ou collez ou choisissez le fichier de métadonnées. Nous affichons l’ID d’entité de votre fournisseur d’identité, son URL de connexion et la date d’expiration de son certificat.
  3. Choisissez l’équipe que les personnes rejoignent à leur première connexion, et leur rôle : membre, lecteur ou administrateur. Jamais propriétaire ni facturation. Les personnes déjà dans une équipe de l’organisation restent où elles sont.
  4. Choisissez Enregistrer les réglages. Nous lisons tout de suite les réglages de votre fournisseur d’identité : une URL d’émetteur mal saisie ou un mauvais fichier de métadonnées apparaît maintenant, pas quand les gens essaient de se connecter.

Le test de connexion

Choisissez Tester la connexion. Vous passez par votre fournisseur d’identité, vous vous connectez avec votre propre compte, et vous revenez sur la page des réglages avec le résultat.

  • Personne ne peut utiliser l’authentification unique tant qu’un test n’a pas réussi.
  • Tout changement de l’URL de l’émetteur, de l’ID client, du secret client ou de la façon d’envoyer le secret demande un nouveau test. En SAML, c’est aussi le cas d’un nouvel ID d’entité du fournisseur d’identité, d’une nouvelle URL de connexion ou d’un certificat qui remplace l’actuel.
  • Testez avec votre propre compte. Un test qui vous connecte vous-même relie aussi votre compte 50heads à la connexion de votre entreprise.

L’activer

Une fois un test réussi, choisissez Activer. Les personnes ayant une adresse e-mail sur vos domaines vérifiés voient alors Continuer avec la connexion de l’entreprise quand elles saisissent leur e-mail sur la page de connexion. Les codes par e-mail, Apple, Google et les clés d’accès restent possibles.

À la première connexion de cette façon :

  • Si la personne n’a pas de compte 50heads, nous en créons un et l’ajoutons à l’équipe choisie, avec le rôle choisi.
  • Si elle a déjà un compte 50heads avec cette adresse, nous ne fusionnons jamais sur la seule adresse e-mail. Nous envoyons un code unique à 6 chiffres à cette adresse. Elle le saisit une fois, et ensuite la connexion de son entreprise ouvre son compte existant.

La rendre obligatoire

Choisissez La rendre obligatoire pour que votre fournisseur d’identité soit le seul moyen d’entrer pour les adresses de vos domaines vérifiés. Pour cela, vous devez avoir fait vous-même, avec votre propre compte, un test réussi depuis le dernier changement. Ainsi, vous ne pouvez pas vous bloquer l’accès.

Tant que l’authentification unique est obligatoire :

  • Nous n’envoyons pas de code par e-mail aux adresses de vos domaines vérifiés. La page de connexion les envoie vers la connexion de leur entreprise.
  • La connexion avec Apple, Google ou une clé d’accès ne fonctionne plus pour ces adresses, sauf pour les propriétaires de secours.
  • Quand vous l’activez, les membres de vos équipes sur ces domaines qui s’étaient connectés autrement sont déconnectés, et se reconnectent avec votre fournisseur d’identité. Les propriétaires de secours restent connectés, tout comme la session avec laquelle vous l’avez activée.
  • Les réglages du fournisseur sont verrouillés, sauf les changements de certificat SAML faits avec Garder aussi le certificat actuel (voir plus bas). Pour modifier autre chose, cessez d’exiger l’authentification unique, faites le changement et testez à nouveau.

Vous pouvez cesser de l’exiger à tout moment, et les codes par e-mail fonctionnent à nouveau tout de suite. Si un de vos domaines n’est plus considéré comme vérifié, l’obligation s’arrête aussitôt pour ce domaine : personne ne se retrouve bloqué.

Les changements de certificat SAML

Votre fournisseur d’identité signe chaque connexion SAML avec un certificat, et les certificats expirent. La page des réglages affiche la date d’expiration de chacun, et vous prévient 30 jours avant.

Pour changer de certificat sans interrompre les connexions :

  1. Récupérez chez votre fournisseur d’identité les métadonnées avec le nouveau certificat. La plupart des fournisseurs permettent d’ajouter un nouveau certificat avant de l’activer.
  2. Dans 50heads, saisissez de nouveau l’URL des métadonnées (ou le nouveau fichier) et cochez Garder aussi le certificat actuel. 50heads accepte alors les deux, et l’authentification unique reste activée, même quand elle est obligatoire.
  3. Activez le nouveau certificat chez votre fournisseur d’identité.
  4. Dans 50heads, choisissez Ne plus accepter à côté de l’ancien certificat.

50heads accepte 2 certificats à la fois au maximum. Remplacer un certificat sans garder l’ancien compte comme une modification des réglages du fournisseur : il faut un nouveau test, et ce n’est pas possible tant que l’authentification unique est obligatoire.

La connexion depuis la liste d’applications du fournisseur d’identité (SAML)

En SAML, on peut aussi partir de la vignette 50heads dans la liste d’applications de l’entreprise (on parle parfois de connexion initiée par le fournisseur d’identité). C’est désactivé tant que vous n’activez pas Autoriser la connexion depuis la liste d’applications du fournisseur d’identité.

Les connexions qui commencent chez votre fournisseur d’identité ne peuvent pas être rattachées à une demande de 50heads, alors nous sommes plus stricts. Chacune n’est acceptée qu’une fois, dans les 5 minutes après sa création par votre fournisseur d’identité, et mène toujours à l’accueil de 50heads, quoi que demande l’application. Laissez cette option désactivée sauf si vos équipes ont besoin de la vignette. Les connexions qui partent de la page de connexion de 50heads fonctionnent dans tous les cas.

Les propriétaires de secours

Les propriétaires de secours peuvent toujours se connecter avec une clé d’accès quand l’authentification unique est obligatoire. Ils servent si votre fournisseur d’identité est en panne ou mal configuré.

  • Vous pouvez en avoir 2 au maximum. Ils doivent être propriétaires d’une des équipes de l’organisation, avec une clé d’accès sur leur compte 50heads.
  • Seuls les propriétaires peuvent en ajouter ou en retirer.
  • Chaque connexion de secours est inscrite dans le journal d’activité et envoyée par e-mail à tous les administrateurs.
  • Les modifications de l’authentification unique faites après une connexion de secours demandent une nouvelle vérification avec une clé d’accès ou une application d’authentification.

L’app 50heads

Dans l’app, on saisit son e-mail professionnel comme d’habitude. Si l’organisation utilise l’authentification unique, l’app ouvre la page de connexion de l’entreprise dans une fenêtre de navigateur sécurisée et ramène la personne connectée. Si son compte doit être relié, l’app demande le code à 6 chiffres reçu par e-mail.

Le journal des connexions et l’activité

Le Journal des connexions liste les connexions et tests par authentification unique qui ont échoué ou demandé un code, du plus récent au plus ancien, avec le code d’erreur. Nous ne gardons jamais les jetons envoyés par votre fournisseur d’identité. L’Activité enregistre chaque changement : configuration, tests, activation et désactivation, obligation, comptes reliés et secours.

Chaque événement d’authentification unique figure aussi dans le journal d’audit, où les admins peuvent le filtrer et l’exporter.

Corriger les erreurs

Le journal des connexions et le résultat du test affichent un code. Voici ce que chacun signifie.

Code Ce que cela veut dire Ce qu’il faut vérifier
state_invalid La connexion a pris trop de temps (plus de 10 minutes) ou a déjà servi. Recommencez.
sso_unavailable L’authentification unique n’est pas active pour l’organisation. Activez-la, ou connectez-vous autrement.
idp_error Le fournisseur d’identité a arrêté la connexion, par exemple parce que la personne n’est pas attribuée à l’application. Les attributions chez votre fournisseur d’identité.
idp_unreachable Nous n’avons pas pu joindre votre fournisseur d’identité. Sa page d’état. Les propriétaires de secours peuvent toujours entrer.
idp_timeout Votre fournisseur d’identité n’a pas répondu en 6 secondes. Sa page d’état, puis réessayez.
discovery_invalid Les réglages de l’émetteur n’ont pas pu être lus, ou indiquent un autre émetteur. L’URL de l’émetteur, exactement. Pour Entra, l’ID du locataire et /v2.0.
token_exchange_failed Votre fournisseur d’identité a refusé le code de connexion. L’ID client, le secret client (Entra : la valeur, pas l’ID), la façon d’envoyer le secret et l’URI de redirection.
id_token_invalid La réponse de votre fournisseur d’identité n’a pas pu être lue. Les réglages de l’application chez votre fournisseur d’identité.
id_token_alg La réponse était signée d’une façon que nous n’acceptons pas. Utilisez RS256, ES256 ou PS256.
id_token_signature La signature de la réponse n’était pas valide. Les clés de signature publiées par votre fournisseur d’identité.
id_token_issuer La réponse venait d’un autre émetteur. L’URL de l’émetteur.
id_token_audience La réponse était destinée à une autre application. L’ID client.
id_token_expired La réponse était trop ancienne. L’horloge du fournisseur d’identité. Un écart de 2 minutes au plus est accepté.
id_token_not_yet_valid La réponse était datée dans le futur. L’horloge du fournisseur d’identité.
id_token_nonce La réponse ne correspondait pas à cette connexion. Recommencez.
unknown_key La réponse était signée avec une clé que votre fournisseur d’identité ne publie pas. Les clés de signature, puis réessayez.
email_missing Votre fournisseur d’identité n’a pas envoyé d’adresse e-mail. Le scope email, et la revendication facultative email d’Entra.
email_unverified Votre fournisseur d’identité n’a pas confirmé l’adresse e-mail. Okta : l’adresse de l’utilisateur est vérifiée. Entra : la revendication xms_edov.
domain_not_verified L’adresse e-mail n’est pas sur un de vos domaines vérifiés. Vérifiez le domaine, ou corrigez l’adresse de la personne.
hd_mismatch Un compte Google extérieur à votre Workspace. Utilisez un compte Workspace.
sso_identity_conflict Le compte 50heads de cette adresse est déjà relié à une autre identité chez votre fournisseur d’identité. Le compte de la personne chez votre fournisseur d’identité.
account_unavailable Nous n’avons pas pu ouvrir ou créer le compte 50heads. Contactez-nous.

SAML a ses propres codes :

Code Ce que cela veut dire Ce qu’il faut vérifier
saml_metadata_invalid Les métadonnées n’ont pas pu être lues ou utilisées. Qu’il s’agit des métadonnées d’une application SAML 2.0, avec une URL de connexion HTTP-Redirect et un certificat de signature, et que les requêtes signées sont désactivées.
saml_response_invalid La réponse de votre fournisseur d’identité n’a pas pu être lue. Les réglages de l’application chez votre fournisseur d’identité.
saml_status Votre fournisseur d’identité indique que la connexion n’a pas abouti, par exemple parce que la personne n’est pas attribuée à l’application. Les attributions chez votre fournisseur d’identité.
saml_unsigned Ni la réponse ni son assertion n’étaient signées. Activez la signature des assertions.
saml_signature La signature ne correspondait pas au certificat que nous avons. Le certificat. Après un changement de certificat, ajoutez les nouvelles métadonnées.
saml_signature_alg La réponse était signée en SHA-1 ou d’une autre façon que nous n’acceptons pas. Utilisez RSA-SHA256.
saml_wrapping La réponse était construite d’une façon que nous refusons, par exemple avec plus d’une assertion. Les réglages de votre fournisseur d’identité. Si cela se reproduit, contactez-nous.
saml_encrypted L’assertion était chiffrée. Désactivez le chiffrement des assertions.
saml_issuer La réponse venait d’un autre fournisseur d’identité. Les métadonnées.
saml_audience La réponse était destinée à une autre application. L’ID d’entité (audience) chez votre fournisseur d’identité.
saml_recipient La réponse était adressée à une autre URL de réponse. L’URL ACS chez votre fournisseur d’identité.
saml_destination La réponse a été envoyée à une autre adresse. L’URL ACS chez votre fournisseur d’identité.
saml_in_response_to La réponse ne correspondait à aucune connexion lancée sur 50heads, ou cette connexion a pris plus de 10 minutes. Recommencez depuis la page de connexion de 50heads.
saml_expired La réponse était trop ancienne. L’horloge du fournisseur d’identité. Un écart de 2 minutes au plus est accepté.
saml_not_yet_valid La réponse était datée dans le futur. L’horloge du fournisseur d’identité.
saml_subject La réponse ne désignait personne que nous puissions utiliser. Le Name ID : l’adresse e-mail de la personne.
saml_replay Cette réponse a déjà servi. Recommencez.
saml_idp_initiated Quelqu’un est parti de la liste d’applications, mais c’est désactivé pour votre organisation. Partez de la page de connexion de 50heads, ou autorisez la connexion depuis la liste d’applications.

À lire aussi