> ## 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

> Découvrez ce qu’est l’authentification unique (SSO) et comment elle fonctionne.

<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="/fr-CA/docs/glossary?term=Single+Sign-on">Authentification unique</Tooltip> (SSO) a lieu 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 la déconnexion unique.

Le SSO offre une expérience fluide aux utilisateurs lorsqu’ils utilisent vos applications et services. Au lieu d’avoir à retenir des identifiants différents pour chaque application ou service, les utilisateurs peuvent simplement se connecter une seule fois et accéder à l’ensemble de vos applications.

Chaque fois que les 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é sur le 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 (SSO) et la déconnexion unique sont possibles grâce aux [sessions](/fr-CA/docs/manage-users/sessions). Un utilisateur ayant recours au SSO peut avoir jusqu’à trois sessions différentes :

* Session locale maintenue par l’application
* Session du <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 accessibles à un utilisateur." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Authorization+Server">serveur d’autorisation</Tooltip>, si le SSO est activé
* Session du <Tooltip tip="Fournisseur d’identité (IdP) : service qui stocke et gère les identités numériques." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Identity+Provider+%28IdP%29">fournisseur d’identité (IdP)</Tooltip>, si l’utilisateur a choisi de se connecter par l’intermédiaire d’un <Tooltip tip="Fournisseur d’identité (IdP) : service qui stocke et gère les identités numériques." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Identity+Provider">fournisseur d’identité</Tooltip> (comme Google, Facebook ou un fournisseur d’identité <Tooltip tip="Security Assertion Markup Language (SAML) : protocole normalisé permettant à deux parties d’échanger des informations d’authentification sans mot de passe." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=SAML">SAML</Tooltip> d’entreprise)

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

Par exemple, le domaine d’authentification peut générer un [JSON Web Token (JWT)](/fr-CA/docs/secure/tokens/json-web-tokens) signé (chiffré à l’aide de JSON Web Encryption (JWE)), qui contient toute l’information nécessaire pour identifier l’utilisateur auprès de tout autre domaine nécessitant une authentification. Ce jeton est transmis à l’application, mais comme il est signé, l’application ne peut le modifier d’aucune façon. Le jeton peut être transmis 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 de mettre en œuvre l’authentification unique (SSO) avec Auth0 consiste à utiliser [Universal Login](/fr-CA/docs/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="/fr-CA/docs/glossary?term=Universal+Login">Universal Login</Tooltip>. Les guides de démarrage rapide [Swift](/fr-CA/docs/quickstart/native/ios-swift) et [Android](/fr-CA/docs/quickstart/native/ios-swift) fournissent quelques exemples d’utilisation d’Universal Login.

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

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

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

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

Pour le SSO avec Auth0, le **service central** est le <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="/fr-CA/docs/glossary?term=Authorization+Server">serveur d’autorisation</Tooltip> d’Auth0.

Voici un exemple du 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="Écran de connexion d’une application de feuilles de temps" width="283" height="527" data-path="docs/images/cdy7uua7fh8z/6m01sxT4xI0oUC6ox3vb4Z/ca72f1208d952a9a43f24f425d360e48/Screenshot_2024-07-11_at_11.57.33.png" />
   </Frame>
4. Une fois l’utilisateur connecté, Auth0 définira 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 flux SSO lorsqu’un utilisateur revient sur votre site Web plus tard :

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 informations sur l’identité de l’utilisateur.

<div id="check-users-sso-status">
  ### Vérifier le statut SSO de l’utilisateur
</div>

Vous pouvez vérifier le statut SSO d’un utilisateur depuis une application en appelant la méthode `checkSession` du SDK `auth0.js`, qui tentera [d’authentifier l’utilisateur en mode silencieux](/fr-CA/docs/authenticate/login/configure-silent-authentication) dans une 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 utilisateur entre domaines." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=WS-Fed">WS-Fed</Tooltip>) sont tous deux des [protocoles](/fr-CA/docs/authenticate/protocols) largement utilisés dans les implémentations de 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 peut 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 peut y accéder.

<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 les renseignements de connexion." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=OpenID">OpenID</Tooltip> Connect (OIDC) est un protocole d’authentification couramment utilisé dans les implémentations de SSO destinées au grand public. Le protocole OIDC gère l’authentification au moyen de <Tooltip tip="Jeton Web JSON (JWT) : format normalisé d’ID Token (et souvent de Jeton d’accès) utilisé pour représenter de façon sécurisée des revendications entre deux parties." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=JSON+Web+Tokens">jetons Web JSON</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 l’authentifier.
3. Le fournisseur d’identité vérifie l’utilisateur et, si l’authentification réussit, lui demande d’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 informations sur l’identité de l’utilisateur que l’application peut exploiter.
5. Le fournisseur d’identité redirige l’utilisateur vers l’application.

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

Lightweight Directory Access Protocol (LDAP) est un protocole applicatif utilisé pour accéder à un annuaire d’identifiants pouvant être partagé par plusieurs applications; il est couramment utilisé dans les intranets. Lorsqu’il est associé à Active Directory (AD), LDAP fournit un point centralisé pour l’identité des utilisateurs, et l’application envoie alors une demande 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](/fr-CA/docs/authenticate/single-sign-on/inbound-single-sign-on), Auth0 est le fournisseur de services SSO (SP).

Lorsqu’un utilisateur se connecte à une application :

1. L’application présente à 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 SP est géré par des connexions.

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

Pour le [SSO initié par le fournisseur d’identité](/fr-CA/docs/authenticate/single-sign-on/outbound-single-sign-on), un fournisseur d’identité (IdP) tiers agit comme fournisseur de 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 d’une mise en œuvre de SSO initié par l’IdP, vous pouvez choisir d’utiliser la [SSO Dashboard Extension](/fr-CA/docs/customize/extensions/single-sign-on-dashboard-extension/create-sso-dashboard-application), qui vous permet de créer un tableau de bord répertoriant plusieurs applications d’entreprise pouvant être activées pour le SSO. Ce tableau de bord est ensuite présenté à vos utilisateurs pour qu’ils puissent s’y connecter.

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

<div id="business-to-business">
  ### Entre entreprises
</div>

Dans les scénarios entre entreprises (B2B), le SSO peut simplifier l’adaptation de votre application aux besoins 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 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">
  ### CIAM Business-to-Consumer
</div>

Dans les scénarios Business-to-Consumer (B2C), ou de gestion des identités et des accès des clients (CIAM), l’authentification unique (SSO) peut offrir un accès sans friction à vos applications ou services. Vous pouvez permettre aux clients de s’authentifier au moyen de fournisseurs d’identité populaires de réseaux sociaux, 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)