--- title: "Configurer le SSO avec Google Workspace" description: "Enregistrez une connexion SAML ou OIDC Bird dans Google Workspace, désactivez la signature de la réponse, activez l'accès utilisateur et tenez compte du délai de propagation de Google." canonical: "https://bird.com/fr-fr/documentation/knowledge-base/account-security/sso-google-workspace" --- # Configurer le SSO avec Google Workspace Cette page couvre la partie Google Workspace d'une connexion SSO. La partie Bird (vérifier un domaine, tester, activer et imposer le SSO) est la même pour tous les fournisseurs et se trouve sur [SSO et provisionnement](/docs/knowledge-base/account-security/sso). Google et Bird ont chacun besoin de valeurs de l'autre, donc le point de départ dépend du protocole. Gardez les deux ouverts pendant la configuration. Deux comportements de Google causent la plupart des premiers tests échoués, et aucun des deux ne signale quoi que ce soit à Bird : - **Activez l'accès utilisateur avant de tester.** Une nouvelle application SAML personnalisée est désactivée par défaut pour tout le monde. Tant que vous ne l'activez pas pour les personnes qui doivent se connecter, Google refuse de son côté et la fenêtre de test n'affiche rien. - **Attendez quelques minutes après l'enregistrement.** Google applique les modifications d'une application SAML (signature de la réponse, format du Name ID, accès utilisateur) après un délai d'environ deux à quatre minutes. Un test lancé pendant ce délai rapporte la configuration précédente, ce qui ressemble à un problème Bird mais n'en est pas un. ## SAML Commencez dans Bird pour SAML. L'Entity ID et l'Assertion Consumer Service URL d'une connexion SAML dérivent de la connexion elle-même : créez-la avec **I have not set up my provider yet**, enregistrez les valeurs qu'elle affiche, puis revenez à **Supply the details**. [Configurer SAML sans valeurs provisoires](/docs/knowledge-base/account-security/sso) décrit ce flux. Google ne publie pas d'URL de métadonnées pour une application SAML personnalisée. Téléchargez le fichier de métadonnées depuis la console d'administration Google et collez son contenu dans **Supply the details** sur la connexion Bird, en choisissant l'option document de métadonnées. Les noms de champs de Google ne correspondent pas à ceux de Bird : | Dans Bird, sous **Register these with your identity provider** | Dans Google Workspace | | -------------------------------------------------------------- | --------------------- | | Assertion Consumer Service URL | ACS URL | | Entity ID | Entity ID | | Sign-in URL for this connection | Start URL (optional) | ### Désactiver Signed response Laissez **Signed response** décoché. Lorsqu'il est coché, Google signe la réponse et laisse l'assertion qu'elle contient non signée, et Bird vérifie la signature propre de l'assertion : chaque connexion est donc refusée avec une erreur de signature qui ressemble à un problème de certificat. En le décochant, l'assertion redevient signée et les connexions aboutissent. ### Identifier les membres par leur adresse e-mail Réglez **Name ID format** sur `EMAIL`. Les autres formats de Google ne fonctionnent pas avec Bird : - `UNSPECIFIED` est refusé directement. - `PERSISTENT` est refusé parce que le format ne correspond pas à celui attendu par la connexion. Google envoie de toute façon l'adresse e-mail du membre comme valeur, ce n'est donc pas l'identifiant opaque et non réattribuable qu'un format persistant est censé porter. Google ne propose pas d'identifiant opaque pour le NameID, donc `EMAIL` est le seul choix utilisable ici. L'adresse devient alors permanente pour quiconque se connecte via cette connexion : si votre organisation la réattribue un jour, la personne suivante qui la reçoit hérite du compte Bird. Lisez [Comment les membres sont identifiés](/docs/knowledge-base/account-security/sso) avant de vous y fier. ### Validité de l'assertion et certificats Google signe des assertions valides de cinq minutes avant l'émission jusqu'à cinq minutes après, ce que Bird accepte. Google gère le certificat de signature et sa date d'expiration, et ne vous donne aucun contrôle de rotation sur une application SAML personnalisée. Notez la date d'expiration affichée sur la connexion Bird et prévoyez de remplacer les métadonnées avant qu'elle ne soit dépassée, car toutes les connexions via cette connexion échouent le jour où elle expire. ## OIDC Commencez dans la console Google Cloud pour OIDC. Bird a besoin de l'émetteur, de l'ID client et du secret client pour créer une connexion OIDC : enregistrez donc d'abord l'application chez Google. L'**URI de redirection** de Bird est la même pour toutes les connexions et s'affiche dans **Add connection** avant toute création, vous pouvez donc l'enregistrer dès le départ. Créez des identifiants client OAuth dans la console Google Cloud pour le projet qui dessert vos utilisateurs Workspace, et copiez l'ID client et le secret dans Bird avec `https://accounts.google.com` comme **Issuer**. Bird lit le document de découverte à partir de là et s'authentifie auprès du point de terminaison de jeton avec `client_secret_basic`. Enregistrez l'**URI de redirection** de Bird comme URI de redirection autorisée sur le client. Le parcours OIDC de Google n'a pas d'étape de tuile d'application : un client OAuth personnalisé n'apparaît pas dans le lanceur d'applications Google, les membres commencent donc depuis la page de connexion de Bird ou depuis un lien que vous leur fournissez. ## Étapes suivantes - [SSO et provisionnement](/docs/knowledge-base/account-security/sso) : vérifier un domaine, tester la connexion et imposer le SSO - [Configurer le SSO avec Okta](/docs/knowledge-base/account-security/sso-okta) - [Configurer le SSO avec Microsoft Entra ID](/docs/knowledge-base/account-security/sso-microsoft-entra-id) ## Related resources - [Should I use an API key or an OAuth token, and how do I rotate one?](/explained/platform/api-key-or-oauth-token-and-how-do-i-rotate-one) (answer) - [Authentication & API keys](/docs/guides/authentication) (docs) [Get an implementation brief](/learn/workspace?topic=account-access)