--- title: "Configurer le SSO avec Okta" description: "Enregistrez une connexion SAML ou OIDC Bird dans Okta, faites correspondre les noms de champs d'Okta avec ceux de Bird, choisissez un format NameID et effectuez la rotation du certificat de signature." canonical: "https://bird.com/fr-fr/documentation/knowledge-base/account-security/sso-okta" --- # Configurer le SSO avec Okta Cette page couvre la partie Okta d'une connexion SSO. La partie Bird (vérifier un domaine, tester, activer et exiger le SSO) est identique pour tous les fournisseurs et se trouve sur [SSO et provisionnement](/docs/knowledge-base/account-security/sso). Okta et Bird ont chacun besoin de valeurs provenant de l'autre, donc le point de départ dépend du protocole. Gardez les deux ouverts pendant la configuration. ## 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 affichées, puis revenez à **Supply the details**. [Configurer SAML sans valeurs temporaires](/docs/knowledge-base/account-security/sso) décrit ce flux. Les noms de champs d'Okta ne correspondent pas à ceux de Bird. Deux d'entre eux sont assez proches pour être intervertis par erreur, et les intervertir envoie la réponse de connexion à une URL qui ne peut pas la traiter. | Dans Bird, sous **Register these with your identity provider** | Dans Okta | | -------------------------------------------------------------- | --------------------------------------------------------------- | | Assertion Consumer Service URL | Single sign-on URL | | Entity ID | Audience URI (SP Entity ID) | | Sign-in URL for this connection | Pas un champ Okta. Communiquez-le aux membres comme marque-page | Le champ **Single sign-on URL** d'Okta correspond à l'Assertion Consumer Service URL de Bird, et non à l'URL de connexion de Bird. Si vous collez l'URL de connexion à cet endroit, Okta envoie chaque réponse au mauvais point de terminaison et la connexion échoue. ### Identifier les membres par leur adresse e-mail Dans le champ **Name ID format** de l'application SAML, choisissez `EmailAddress` et définissez **Application username** sur la valeur sur laquelle vous voulez que Bird indexe chaque compte. Bird refuse `Unspecified` et refuse toute réponse dont le format NameID ne correspond pas au format attendu par la connexion. Lisez [Comment les membres sont identifiés](/docs/knowledge-base/account-security/sso) avant de décider : l'identifiant est permanent pour toute personne qui se connecte via la connexion, donc un nom d'utilisateur applicatif opaque avec l'adresse envoyée séparément en tant qu'attribut `email` est le choix le plus sûr. ### Validité de l'assertion Okta signe les assertions valides de cinq minutes avant l'émission à cinq minutes après. Bird accepte cette fenêtre. Rien à configurer. ## OIDC Commencez dans Okta pour OIDC. Bird a besoin de l'émetteur, du client ID et du client secret pour créer une connexion OIDC : enregistrez donc l'application dans Okta en premier. Le **Redirect URI** de Bird est le même pour chaque connexion et s'affiche dans **Add connection** avant toute création, vous pouvez donc l'enregistrer d'emblée. Créez une application web OIDC dans Okta et copiez son client ID et son secret dans Bird, avec l'émetteur d'Okta comme **Issuer**. Bird s'authentifie auprès du point de terminaison de jeton avec `client_secret_basic`. Enregistrez le **Redirect URI** de Bird comme URI de redirection de connexion de l'application. ### Tuile d'application Okta Pour permettre aux membres de démarrer depuis leur tableau de bord Okta, définissez : - **Login initiated by** : Either Okta or App - **Application visibility** : la tuile affichée aux utilisateurs - **Login flow** : Redirect to app to initiate login (OIDC Compliant) - **Initiate login URI** : l'URI d'initiation de connexion de la connexion depuis Bird Choisissez le flux conforme OIDC. Le flux **Send ID Token directly to app (Okta Simplified)** d'Okta envoie un jeton directement à Bird au lieu de rediriger, et Bird ne l'accepte pas. ## Assigner l'application Un membre qui n'est pas assigné à l'application Bird dans Okta est refusé par Okta, pas par Bird. Bird signale le refus comme provenant de votre fournisseur d'identité : vérifiez donc les assignations et toute politique d'accès conditionnel dans Okta avant de revérifier les paramètres de la connexion. ## Effectuer la rotation du certificat de signature Effectuez la rotation dans Okta d'abord, puis dans Bird. Bird vérifie les certificats que la connexion détient : une connexion Bird ne contenant que le nouveau certificat alors qu'Okta signe encore avec l'ancien refuse chaque connexion jusqu'à ce qu'Okta active le nouveau. Le refus est une erreur de signature et disparaît dès que les deux concordent. ## Étapes suivantes - [SSO et provisionnement](/docs/knowledge-base/account-security/sso) : vérifier un domaine, tester la connexion et exiger le SSO - [Configurer le SSO avec Google Workspace](/docs/knowledge-base/account-security/sso-google-workspace) - [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)