> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# authentification unique

> Auth0 Single Sign-On (SSO) permet aux utilisateurs de s’authentifier une seule fois et d’accéder à toutes les applications du même locataire sans avoir à saisir de nouveau leurs renseignements d’authentification.

<Tooltip tip="authentification unique (SSO) : service qui, après qu’un utilisateur s’est connecté à une application, le connecte automatiquement à d’autres applications." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Single+Sign-on">authentification unique</Tooltip> (SSO) se produit lorsqu’un utilisateur se connecte à une application, puis est automatiquement connecté à d’autres applications, peu importe la plateforme, la technologie ou le domaine utilisé. L’utilisateur ne se connecte qu’une seule fois, d’où le nom de cette fonctionnalité (authentification unique).

Par exemple, si vous vous connectez à un service Google comme Gmail, vous êtes automatiquement authentifié sur YouTube, AdSense, Google Analytics et d’autres applications Google. De même, si vous vous déconnectez de Gmail ou d’autres applications Google, vous êtes automatiquement déconnecté de toutes les applications; c’est ce qu’on appelle le Single Logout.

Le SSO offre une expérience fluide aux utilisateurs de vos applications et services. Au lieu d’avoir à mémoriser des renseignements d’authentification distincts pour chaque application ou service, les utilisateurs peuvent simplement se connecter une seule fois et accéder à l’ensemble de votre suite d’applications.

Chaque fois que des utilisateurs accèdent à un domaine qui exige une authentification, ils sont redirigés vers le domaine d’authentification, où il peut leur être demandé de se connecter. Si l’utilisateur est déjà connecté au domaine d’authentification, il peut être redirigé immédiatement vers le domaine d’origine sans avoir à se reconnecter.

<div id="how-it-works">
  ## Fonctionnement
</div>

L’authentification unique et le Single Logout sont possibles grâce à l’utilisation de [sessions](/docs/fr-ca/manage-users/sessions). Un utilisateur peut avoir jusqu’à trois sessions différentes avec le SSO :

* Session locale maintenue par l’application
* Session de l’<Tooltip tip="serveur d’autorisation : serveur centralisé qui aide à définir les limites de l’accès d’un utilisateur. Par exemple, votre serveur d’autorisation peut contrôler les données, les tâches et les fonctionnalités auxquelles un utilisateur a accès." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Authorization+Server">serveur d’autorisation</Tooltip>, si le SSO est activé
* Session de l’<Tooltip tip="fournisseur d’identité (IdP) : service qui stocke et gère les identités numériques." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Identity+Provider+%28IdP%29">fournisseur d’identité (IdP)</Tooltip>, si l’utilisateur a choisi de se connecter par l’entremise d’un <Tooltip tip="fournisseur d’identité (IdP) : service qui stocke et gère les identités numériques." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Identity+Provider">fournisseur d’identité</Tooltip> (comme Google, Facebook ou un <Tooltip tip="Security Assertion Markup Language (SAML) : protocole normalisé permettant à deux parties d’échanger des renseignements d’authentification sans mot de passe." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=SAML">SAML</Tooltip> fournisseur d’identité d’entreprise)

Avec le SSO, un domaine central effectue l’authentification, puis partage la session avec d’autres domaines. La façon dont une session est partagée peut varier selon les protocoles SSO, mais le concept général reste le même.

Par exemple, le domaine d’authentification peut générer un [JSON Web Token (JWT)](/docs/fr-ca/secure/tokens/json-web-tokens) signé (chiffré au moyen de JSON Web Encryption (JWE)), qui contient tous les renseignements nécessaires pour identifier l’utilisateur auprès de tout autre domaine exigeant une authentification. Ce jeton est transmis au client, mais comme il est signé, le client ne peut le modifier d’aucune façon. Le jeton peut être renvoyé au domaine d’origine au moyen d’une redirection, puis utilisé par le domaine d’authentification et tout autre domaine pour identifier l’utilisateur.

<div id="sso-with-universal-login">
  ## SSO avec Universal Login
</div>

La façon la plus simple et la plus sécuritaire d’implémenter l’authentification unique (SSO) avec Auth0 est d’utiliser [Universal Login](/docs/fr-ca/authenticate/login/auth0-universal-login) pour l’authentification. En fait, à l’heure actuelle, le SSO n’est possible sur les plateformes natives (comme iOS ou Android) que si l’application utilise <Tooltip tip="Universal Login : votre application redirige vers Universal Login, hébergé sur le serveur d’autorisation d’Auth0, pour vérifier l’identité d’un utilisateur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Universal+Login">Universal Login</Tooltip>. Les guides de démarrage rapide [Swift](/docs/fr-ca/quickstart/native/ios-swift) et [Android](/docs/fr-ca/quickstart/native/ios-swift) fournissent quelques exemples d’utilisation d’Universal Login.

Si vous ne pouvez pas utiliser Universal Login avec votre application, consultez les ressources suivantes pour obtenir plus de renseignements sur l’authentification intégrée :

* [Lock](/docs/fr-ca/libraries/lock/lock-api-reference)
* [Auth0.js](/docs/fr-ca/libraries/auth0js)

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Si vous utilisez [Passwordless](/docs/fr-ca/authenticate/passwordless/passwordless-with-universal-login) avec l’authentification unique, les paramètres de connection `sms` et `email` n’utilisent pas la session Auth0 existante, et l’utilisateur sera invité à se connecter.
</Callout>

<div id="sso-on-first-login">
  ### SSO lors de la première connexion
</div>

Pour le SSO avec Auth0, le **service central** est le <Tooltip tip="Serveur d’autorisation : serveur centralisé qui contribue à définir les limites de l’accès d’un utilisateur. Par exemple, votre serveur d’autorisation peut contrôler les données, les tâches et les fonctionnalités auxquelles un utilisateur a accès." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Authorization+Server">serveur d’autorisation</Tooltip> d’Auth0.

Examinons un exemple de flux SSO lorsqu’un utilisateur se connecte pour la première fois :

1. Votre application redirige l’utilisateur vers la page de connexion.
2. Auth0 vérifie s’il existe déjà un cookie SSO.
3. Comme c’est la première fois que l’utilisateur visite la page de connexion et qu’aucun cookie SSO n’est présent, l’utilisateur devra se connecter à l’aide de l’une des connexions que vous avez configurées.

   <Frame>
     <img src="https://mintcdn.com/translations/6GE5Z24GDCZehiJ9/docs/images/cdy7uua7fh8z/6m01sxT4xI0oUC6ox3vb4Z/ca72f1208d952a9a43f24f425d360e48/Screenshot_2024-07-11_at_11.57.33.png?fit=max&auto=format&n=6GE5Z24GDCZehiJ9&q=85&s=64c63b7963ed2b26118bf3e69231c7a6" alt="Exemple d’écran de connexion de l’application Timesheets" width="283" height="527" data-path="docs/images/cdy7uua7fh8z/6m01sxT4xI0oUC6ox3vb4Z/ca72f1208d952a9a43f24f425d360e48/Screenshot_2024-07-11_at_11.57.33.png" />
   </Frame>
4. Une fois que l’utilisateur s’est connecté, Auth0 créera un cookie SSO et redirigera l’utilisateur vers votre application, en renvoyant un ID Token contenant les renseignements d’identité de l’utilisateur.

<div id="sso-on-subsequent-logins">
  ### SSO lors des connexions ultérieures
</div>

Examinons un exemple du processus SSO lorsqu'un utilisateur revient sur votre site Web pour une visite ultérieure :

1. Votre application redirige l'utilisateur vers la page de connexion.
2. Auth0 vérifie s'il existe déjà un cookie SSO.
3. Auth0 trouve le cookie SSO et, au besoin, le met à jour. Aucun écran de connexion n'est affiché.
4. Auth0 redirige l'utilisateur vers votre application en renvoyant un ID Token qui contient des renseignements sur l’identité de l’utilisateur.

<div id="check-users-sso-status">
  ### Vérifier l’état SSO d’un utilisateur
</div>

Vous pouvez vérifier l’état SSO d’un utilisateur depuis une application en appelant la méthode `checkSession` du SDK `auth0.js`, qui tentera d’[authentifier silencieusement](/docs/fr-ca/authenticate/login/configure-silent-authentication) l’utilisateur dans un iframe. Le succès ou l’échec de l’authentification indique si l’utilisateur a un cookie SSO actif.

<div id="protocols">
  ## Protocoles
</div>

<div id="saml-and-ws-federation">
  ### SAML et WS-Federation
</div>

Security Assertion Markup Language (SAML) et Web Services Federation (<Tooltip tip="Web Service Federation (WS-Fed) : protocole de gestion des identités d’utilisateur entre domaines." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=WS-Fed">WS-Fed</Tooltip>) sont deux [protocoles](/docs/fr-ca/authenticate/protocols) largement utilisés dans les mises en œuvre du SSO. SAML et WS-Fed échangent tous deux des données d’autorisation et d’authentification au format XML; les principaux éléments de cet échange sont l’utilisateur, le fournisseur d’identité et le fournisseur de services.

Avec SAML ou WS-Fed :

1. Un utilisateur demande une ressource au fournisseur de services.
2. Le fournisseur de services vérifie auprès du fournisseur d’identité si l’utilisateur est autorisé à accéder à la ressource.
3. Le fournisseur d’identité vérifie l’identité de l’utilisateur et, si elle est valide, confirme au fournisseur de services que l’utilisateur est autorisé à accéder à la ressource.

<div id="openid-connect">
  ### OpenID Connect
</div>

<Tooltip tip="OpenID : norme ouverte d’authentification qui permet aux applications de vérifier l’identité des utilisateurs sans recueillir ni stocker de renseignements de connexion." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OpenID">OpenID</Tooltip> Connect (OIDC) est un protocole d’authentification couramment utilisé dans les mises en œuvre de SSO destinées au grand public. Le protocole OIDC gère l’authentification au moyen de <Tooltip tip="JSON Web Token (JWT) : format standard d’ID Token (et souvent de jeton d’accès) utilisé pour représenter de façon sécurisée des claims entre deux parties." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=JSON+Web+Tokens">JSON Web Tokens</Tooltip> et d’un fournisseur d’identité central.

Avec OIDC :

1. Un utilisateur demande à accéder à une application.
2. L’application redirige l’utilisateur vers le fournisseur d’identité pour s’authentifier.
3. Le fournisseur d’identité vérifie l’identité de l’utilisateur et, si l’authentification réussit, l’invite à autoriser l’application à accéder aux données.
4. Si l’accès est accordé, le fournisseur d’identité génère un ID Token, qui contient des renseignements sur l’identité de l’utilisateur que l’application peut exploiter.
5. Le fournisseur d’identité renvoie l’utilisateur vers l’application.

<div id="adldap">
  ### AD/LDAP
</div>

Lightweight Directory Access Protocol (LDAP) est un protocole d’application utilisé pour accéder à un annuaire d’informations d’authentification pouvant être partagé par plusieurs applications; il est couramment utilisé dans les intranets. Lorsqu’il est associé à Active Directory (AD), LDAP fournit un emplacement centralisé pour l’identité de l’utilisateur, de sorte que l’application envoie une requête d’authentification au serveur LDAP/AD. Le protocole LDAP échange des informations au format LDAP Data Interchange Format (LDIF).

<div id="service-provider-initiated-sso">
  ## SSO initié par le fournisseur de services
</div>

Pour le [SSO initié par le fournisseur de services](/docs/fr-ca/authenticate/single-sign-on/inbound-single-sign-on), Auth0 agit comme fournisseur de services (SP) du SSO.

Lorsqu’un utilisateur se connecte à une application :

1. L’application propose à l’utilisateur un ou plusieurs fournisseurs d’identité externes.
2. L’utilisateur sélectionne un fournisseur d’identité pour s’authentifier, puis se connecte.
3. Une fois l’authentification réussie, l’utilisateur est redirigé vers l’application.

Dans Auth0, le SSO initié par le fournisseur de services est géré par les connexions.

<div id="identity-provider-initiated-sso">
  ## SSO initié par le fournisseur d’identité
</div>

Pour le [SSO initié par le fournisseur d’identité](/docs/fr-ca/authenticate/single-sign-on/outbound-single-sign-on), un fournisseur d’identité (IdP) tiers agit comme fournisseur SSO.

Lorsqu’un utilisateur se connecte à une application :

1. L’application redirige l’utilisateur vers un fournisseur d’identité.
2. Le fournisseur d’identité tiers effectue l’authentification et l’autorisation.
3. Une fois l’authentification réussie, l’utilisateur est redirigé vers l’application.

Lors de la planification de la mise en œuvre d’un SSO initié par l’IdP, vous pouvez choisir d’utiliser la [SSO Dashboard Extension](/docs/fr-ca/customize/extensions/single-sign-on-dashboard-extension/create-sso-dashboard-application) d’Auth0, qui vous permet de créer un tableau de bord présentant plusieurs applications d’entreprise pouvant être activées pour le SSO. Ce tableau de bord est ensuite présenté à vos utilisateurs afin qu’ils puissent se connecter.

<div id="use-cases">
  ## Cas d’utilisation
</div>

<div id="business-to-business">
  ### Business to Business
</div>

Dans les scénarios Business to Business (B2B), le SSO peut faciliter la commercialisation de votre application auprès des entreprises. Avec Auth0, vos applications peuvent prendre en charge des scénarios courants de fédération d’entreprise, comme Active Directory (AD), Lightweight Directory Access Protocol (LDAP), Ping ou Security Assertion Markup Language (SAML). Cela permet à vos partenaires et à vos clients d’entreprise de se connecter à l’aide des technologies d’identité d’entreprise de leur choix.

* [Étude de cas : O'Reilly](https://auth0.com/case-studies/oreilly)

<div id="business-to-consumer-ciam">
  ### Business to Consumer CIAM
</div>

Pour les scénarios Business to Consumer (B2C) ou de Customer Identity Access Management (CIAM), le SSO peut offrir un accès fluide à vos applications ou services. Vous pouvez permettre aux clients de s’authentifier au moyen de fournisseurs d’identité sociaux populaires, comme Google, Facebook, LinkedIn, X et Microsoft, plutôt que de les obliger à créer un nouveau compte.

* [Étude de cas : Giving Compass](https://auth0.com/case-studies/giving-compass)