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

> Comment l’authentification fonctionne dans votre mise en œuvre B2C IAM.

# Authentification (B2C)

Pour fournir des services à vos utilisateurs, vous devez être en mesure d’identifier qui ils sont. Ce processus s’appelle l’authentification des utilisateurs. Il existe plusieurs façons d’authentifier un utilisateur — au moyen de comptes de médias sociaux, d’un nom d’utilisateur et mot de passe, ou en mode <Tooltip tip="Passwordless: Forme d’authentification qui ne repose pas sur un mot de passe comme premier facteur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=passwordless">sans mot de passe</Tooltip> — et il est souvent recommandé d’aller au-delà d’un premier facteur en activant l’<Tooltip tip="Passwordless: Forme d’authentification qui ne repose pas sur un mot de passe comme premier facteur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=multi-factor+authentication">authentification multifacteur</Tooltip> (MFA).

<Info>
  ### Bonne pratique

  Il est important de tenir compte à la fois de la sécurité et de l’expérience utilisateur lorsque vous concevez la façon dont vous authentifierez vos utilisateurs. Offrir plusieurs facteurs primaires et/ou exiger plus d’un facteur pendant l’authentification sont deux moyens d’assurer les deux.
</Info>

Il y a plusieurs éléments à prendre en considération lorsque vous examinez les fonctionnalités et le workflow :

* Où les utilisateurs saisiront-ils leurs identifiants ?
* Comment protégerez-vous les identifiants des utilisateurs ?
* Comment assurerez-vous la maintenance de votre système d’authentification ?
* Comment pouvez-vous offrir une authentification par mot de passe à vos utilisateurs ?
* Comment pouvez-vous empêcher des pirates d’essayer de se connecter à la place de vos utilisateurs ?
* Comment mettrez-vous en œuvre l’authentification dans différents types d’applications ?
* Comment pouvez-vous faciliter la connexion pour vos utilisateurs de différentes langues ?
* Comment offrirez-vous une bonne expérience utilisateur pendant la migration hors de tout système d’authentification hérité ?
* Que devriez-vous prendre en considération lors de l’intégration d’applications avec Auth0 ?
* Les utilisateurs peuvent-ils se connecter avec leurs comptes sociaux existants (p. ex., Facebook ou Google) ?
* Devez-vous offrir l’authentification multifacteur ?
* Que faites-vous si vous avez un service qui n’offre aucun moyen à l’utilisateur de se connecter à l’avance ?
* Pouvez-vous transmettre le même <Tooltip tip="Access Token: Identifiant d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisé pour accéder à une API." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=access+token">jeton d’accès</Tooltip> utilisateur d’une API à une autre ?

Auth0 [Universal Login](#universal-login) offre aux utilisateurs une expérience sûre et sécurisée, que vous choisissiez d’offrir une connexion par identifiants nom d’utilisateur/mot de passe ou de permettre les scénarios dits Bring Your Own Identity offerts par le [Social Login](https://auth0.com/learn/social-login/). Il y a aussi des avantages sur le plan de la reconnaissance de l’image de marque à centraliser l’expérience de connexion avec <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>, même si vous estimez devoir également répondre à des exigences propres au produit en matière d’[image de marque](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/branding). Les widgets d’interface utilisateur d’Auth0 habituellement utilisés avec Universal Login offrent aussi une prise en charge prête à l’emploi de l’[internationalisation](/docs/fr-ca/customize/internationalization-and-localization/universal-login-internationalization) pour les utilisateurs ayant différentes exigences linguistiques, et la prise en charge prête à l’emploi de fonctionnalités Auth0 comme la [MFA](#multi-factor-authentication-mfa-) et la [protection contre les attaques](#anomaly-detection) vous permet de mettre en place des mesures pour empêcher des pirates de tenter d’accéder aux comptes des utilisateurs.

Permettre aux utilisateurs de se connecter au moyen d’identifiants nom d’utilisateur/mot de passe signifie que vous ne dépendez pas du bon fonctionnement des <Tooltip tip="Identity Provider (IdP): Service qui stocke et gère les identités numériques." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=identity+providers">fournisseurs d’identité</Tooltip> tiers pour que vos utilisateurs accèdent à votre système. Vous avez également les moyens d’exiger que les identifiants utilisés respectent vos politiques d’entreprise. Auth0 vous aide en vous offrant plusieurs options pour prendre en charge les connexions par nom d’utilisateur/mot de passe, et les [directives fournies](#username-and-password-authentication) vous aideront à comprendre comment tirer parti de ces options. Ajouter une prise en charge [sociale](#social-authentication) à une certaine étape, comme facteur d’authentification primaire supplémentaire, vous offre une plus grande flexibilité et peut vous aider à mieux comprendre vos utilisateurs sans devoir leur poser d’autres questions, en tirant parti des renseignements déjà stockés par les divers [fournisseurs](/docs/fr-ca/authenticate/identity-providers/social-identity-providers) de connexion sociale.

Si vous avez déjà un ancien répertoire d’identités, vous voudrez aussi consulter [migration des utilisateurs](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/provisioning). Cette section présente les avantages d’une migration vers le stockage des identités géré par Auth0 sur les plans de la sûreté et de la sécurité.

Pour les applications destinées à la clientèle, <Tooltip tip="OpenID : norme ouverte d’authentification qui permet aux applications de vérifier l’identité des utilisateurs sans recueillir ni stocker d’information de connexion." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OpenID">OpenID</Tooltip> Connect ([OIDC](/docs/fr-ca/authenticate/protocols/openid-connect-protocol)) est le protocole standard du secteur le plus couramment utilisé, et OIDC est pris en charge de façon native par Auth0. Auth0 prend en charge diverses approches pour intégrer différents types d’applications; vous voudrez donc consulter la section sur l’[intégration d’application](#application-integration) pour obtenir l’information nécessaire à un choix éclairé.

Lorsqu’on appelle une API depuis une autre API, ou dans toute situation où il n’y a pas de contexte d’utilisateur authentifié — par exemple, une ou plusieurs tâches cron, des générateurs de rapports ou des systèmes d’intégration/livraison continues — vous aurez besoin d’un moyen d’autoriser l’application plutôt qu’un utilisateur. Il s’agit d’un processus en une étape où l’application est authentifiée (à l’aide d’un <Tooltip tip="Client ID : valeur d’identification attribuée à votre ressource enregistrée par Auth0." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=client+ID">ID client</Tooltip> et d’un secret), puis autorisée en une seule requête. Vous pouvez en apprendre davantage à ce sujet dans notre volet sur l’autorisation, sous [l’autorisation machine-to-machine (m2m)](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/authorization).

<div id="universal-login">
  ## Universal Login
</div>

Avez-vous, ou prévoyez-vous avoir, plus d’une application dans votre système ? Si la réponse est oui, vous aurez avantage à offrir une expérience de connexion centralisée. Pour offrir une expérience <Tooltip tip="Single Sign-On (SSO) : service qui, après qu’un utilisateur ouvre une session dans une application, ouvre automatiquement une session pour cet utilisateur dans d’autres applications." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Single+Sign-on">d’authentification unique</Tooltip> (SSO) fluide entre plusieurs applications, il est essentiel de disposer d’un point central vers lequel rediriger vos utilisateurs pour l’authentification. Vous pouvez ainsi offrir à vos utilisateurs une expérience cohérente si vous ajoutez de l’authentification sociale plus tard, intégrez des applications tierces à votre système ou proposez l’authentification multifacteur comme option (ou exigence) — tout en profitant de nouvelles fonctionnalités pour améliorer leur expérience avec peu, voire aucun, effort de développement supplémentaire.

<Info>
  ### Pratique exemplaire

  Si vous avez plus d’une application, la pratique exemplaire consiste à rediriger l’utilisateur vers un [point central](/docs/fr-ca/authenticate/login/auth0-universal-login) pour l’authentifier. Avec Auth0, cela signifie tirer parti de [Universal Login](/docs/fr-ca/authenticate/login/auth0-universal-login), qui offre d’emblée de nombreux avantages sur le plan de la sécurité et de l’expérience utilisateur, y compris le [SSO](/docs/fr-ca/authenticate/single-sign-on).
</Info>

Auth0 Universal Login fait de l’authentification des utilisateurs un processus simple et rapide qui peut être réalisé en trois étapes faciles (tous nos Quickstarts le démontrent, et nos SDKs en masquent aussi la complexité) :

1. Déterminez comment et quand vous souhaitez [rediriger depuis votre application](#application-integration).
2. Configurez l’[image de marque](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/branding) appropriée et/ou du HTML personnalisé dans votre configuration Auth0.
3. Configurez votre application pour [recevoir et traiter la réponse](#application-integration) du serveur d’autorisation.

<div id="username-and-password-authentication">
  ## Authentification par nom d’utilisateur et mot de passe
</div>

Presque toutes les applications B2C permettent à leurs clients de créer de nouveaux identifiants. Il s’agit d’une forme courante d’authentification que tous les utilisateurs connaissent bien.

Dans Auth0, l’authentification par nom d’utilisateur et mot de passe se présente sous plusieurs formes. Si votre application est nouvelle et ne compte encore aucun utilisateur, une simple [Database Connection](/docs/fr-ca/authenticate/database-connections) prête à l’emploi d’Auth0 vous donnera tout ce qu’il faut pour commencer à authentifier vos utilisateurs. En revanche, si vous avez un ancien répertoire d’utilisateurs — par exemple votre propre base de données d’utilisateurs ou un système LDAP existant — différentes options s’offrent à vous pour migrer vos utilisateurs, comme l’explique notre guide sur la [migration des utilisateurs](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/provisioning).

Quelle que soit la façon dont vous provisionnez les utilisateurs dans votre connexion de base de données, l’authentification de ces utilisateurs reste sensiblement la même. Vous devez leur présenter un formulaire dans lequel ils entreront leur nom d’utilisateur et leur mot de passe. Comme indiqué dans la section sur [Universal Login](#universal-login), la manière la plus simple et la plus sûre d’authentifier les utilisateurs avec un nom d’utilisateur et un mot de passe consiste à les rediriger vers une page de connexion centralisée pour y recueillir ces renseignements. Auth0 peut ainsi déterminer s’ils se sont déjà authentifiés et ne pas afficher le formulaire de connexion lorsqu’il n’est pas nécessaire.

<Info>
  ### Bonne pratique

  Le fait de recueillir les identifiants uniquement sur la page de connexion centralisée réduit les risques de fuite potentielle des secrets des utilisateurs. Cela évite aussi de demander des identifiants inutilement. Consultez [Universal Login](#universal-login) pour en savoir plus.
</Info>

<div id="application-integration">
  ## Intégration de l’application
</div>

Une fois que vous avez déterminé comment vous souhaitez authentifier vos utilisateurs, l’étape suivante consiste à établir comment vous allez lancer cette authentification. Chaque application aura généralement son propre point de départ.

<Warning>
  Les applications mobiles Native (et les applications de bureau) devraient utiliser le navigateur du système pour l’authentification, faute de quoi elles s’exposent à des risques de sécurité supplémentaires. Consultez [Native Login](/docs/fr-ca/authenticate/login/native-login) pour en savoir plus.
</Warning>

Comme nous l’avons mentionné, nous avons constaté que la plupart de nos clients utilisent [OpenID Connect (OIDC)](/docs/fr-ca/authenticate/protocols/openid-connect-protocol) comme protocole standard de l’industrie pour leurs applications destinées à la clientèle. Déterminer quel flux OIDC utiliser est votre première tâche, et vous devriez commencer par consulter d’abord nos conseils sur le [grant mapping](/docs/fr-ca/get-started/applications/application-grant-types).

Si vous souhaitez permettre à des utilisateurs anonymes d’accéder à une partie de votre application, vous devez déterminer si vous allez les rediriger immédiatement ou ne leur demander de se rediriger qu’au besoin (ou peut-être une combinaison des deux; consultez [Redirect Users After Login](/docs/fr-ca/authenticate/login/redirect-users-after-login) pour en savoir plus). Si les utilisateurs peuvent accéder directement, par [lien profond](#deep-linking-to-protected-endpoints), à une version protégée (ou à une zone protégée) de votre site, vous devrez déterminer quels liens vers votre application déclencheront une redirection automatique vers Auth0.

<div id="anonymous-access">
  ### Accès anonyme
</div>

Il est important de tenir compte de l’expérience utilisateur lorsqu’une personne arrive pour la première fois dans votre application. Si votre application prend en charge l’accès anonyme (ce qui est assez courant pour les applications de commerce électronique), différents scénarios sont à considérer :

* Revient-elle dans l’application après s’être déjà connectée, ou
* S’il s’agit de la première fois qu’elle accède à l’application :

  * A-t-elle déjà accédé à une autre application qui utilise le même tenant Auth0,
  * S’est-elle déjà authentifiée sur cet appareil ou dans ce navigateur, ou peut-être pas depuis longtemps.

Lorsqu’un utilisateur anonyme accède à votre application, il peut souvent être souhaitable que l’application détermine si l’utilisateur s’est déjà connecté à une autre application de la même famille, ou qu’elle se souvienne de cet utilisateur même si l’application est une [SPA](/docs/fr-ca/quickstart/spa) sans état. Par exemple, si vous pouvez déterminer que l’utilisateur est déjà connecté, vous pourriez décider que l’en-tête de l’interface utilisateur de l’application n’affiche pas de bouton de connexion et présente plutôt un menu de compte ou de profil. Pour y parvenir, vous devrez utiliser l’« [authentification silencieuse](/docs/fr-ca/authenticate/login/configure-silent-authentication) ». L’authentification silencieuse vous permettra de vérifier si l’utilisateur est connecté sans lui demander de se connecter si ce n’est pas le cas. L’application pourra alors afficher un bouton de connexion au besoin. Si l’utilisateur est déjà connecté, toutefois, vous recevrez des jetons et n’aurez pas à lui présenter de nouveau un bouton de connexion.

<Warning>
  Vérifier l’existence d’une session de connexion en redirigeant l’utilisateur vers Auth0 peut être utile pour votre application, mais si cela entraîne un grand nombre de requêtes, vous devriez mettre en place un mécanisme de régulation afin d’éviter la latence ou une limitation du nombre de requêtes.

  Les requêtes adressées à la Management API sont assujetties à la [politique de limitation du nombre de requêtes d’Auth0](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy). Vous devez en tenir compte et, pour vous aider, Auth0 recommande généralement d’utiliser l’[Auth0 SDK](/docs/fr-ca/libraries) approprié à votre environnement de développement plutôt que d’appeler directement nos API.
</Warning>

<div id="deep-linking-to-protected-endpoints">
  ### Liens profonds vers des points de terminaison protégés
</div>

Il peut y avoir plusieurs raisons pour lesquelles quelqu’un voudrait créer un lien direct vers une page précise de votre application qui n’est accessible qu’aux utilisateurs authentifiés. Si c’est le cas pour votre application, vous devriez rediriger automatiquement l’utilisateur vers Auth0 s’il n’est pas authentifié. Une fois qu’il s’authentifie et que 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> le renvoie vers votre application, vous pouvez [le rediriger](/docs/fr-ca/authenticate/login/redirect-users-after-login) vers l’endroit où il voulait aller au départ.

<div id="best-practice">
  ### Bonne pratique
</div>

La plupart des frameworks d’authentification modernes prennent en charge un middleware permettant de rediriger vers un serveur d’autorisation comme Auth0. Au moment d’en choisir un, voici quelques éléments clés à considérer :

* La prise en charge des clients confidentiels, des clients publics ou des deux
* La prise en charge de la configuration au moyen du [point de terminaison de découverte](/docs/fr-ca/get-started/applications/configure-applications-with-oidc-discovery "Configurer les applications avec OIDC Discovery") ou définie explicitement en ligne
* La prise en charge de la validation des jetons, y compris l’expiration, les signatures, les claims et les scopes
* La prise en charge des <Tooltip tip="Jeton d’actualisation : jeton utilisé pour obtenir un nouveau jeton d’accès sans obliger les utilisateurs à se connecter de nouveau." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Refresh+Tokens">jetons d’actualisation</Tooltip>, au besoin

<div id="authenticating-the-user">
  ### Authentification de l’utilisateur
</div>

L’authentification est le processus qui permet d’établir l’identité de l’utilisateur. Le résultat de l’authentification dans un contexte OIDC est un <Tooltip tip="ID Token : jeton destiné au client lui-même plutôt qu’à l’accès à une ressource." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=ID+Token">ID Token</Tooltip>. Ce jeton contient des renseignements sur l’utilisateur et ne devrait pouvoir être obtenu que si l’utilisateur s’authentifie au moyen d’un ou de plusieurs facteurs, tels que définis par le serveur d’autorisation (la forme la plus courante étant l’[ID utilisateur et le mot de passe](#username-and-password-authentication)). Voici aussi quelques éléments dont vous devrez peut-être tenir compte, en plus de l’obtention d’un ID Token :

* Avez-vous aussi besoin d’un [jeton d’accès](/docs/fr-ca/secure/tokens/access-tokens) pour appeler une API partagée ?
* Votre application est-elle une application monopage et a-t-elle seulement besoin d’un [ID Token](/docs/fr-ca/secure/tokens/id-tokens) ? Consultez [l’octroi de code d’autorisation avec PKCE](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/call-your-api-using-the-authorization-code-flow-with-pkce) pour en savoir plus.
* Votre application est-elle une application native (mobile ou de bureau) et/ou avez-vous besoin d’un [Refresh Token](/docs/fr-ca/secure/tokens/refresh-tokens) ? Consultez [l’octroi de code d’autorisation avec PKCE](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/call-your-api-using-the-authorization-code-flow-with-pkce) pour en savoir plus.

<Warning>
  Avant de passer en production, vous devriez vous assurer que **seuls** les types d’octroi que vous utilisez pour chaque application sont activés dans la [configuration de votre application](/docs/fr-ca/get-started/applications/update-grant-types).
</Warning>

<div id="authorization-code-grant-with-or-without-pkce">
  ### Grant de code d’autorisation (avec ou sans PKCE)
</div>

Si votre SDK ne prend en charge que le grant de code d’autorisation, ou si vous avez besoin d’un jeton d’accès ou d’un <Tooltip tip="Refresh Token : jeton utilisé pour obtenir un jeton d’accès renouvelé sans obliger les utilisateurs à se connecter de nouveau." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Refresh+Token">Refresh Token</Tooltip>, le grant de code d’autorisation (avec ou sans [PKCE](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)) peut aussi être utilisé pour récupérer un ID Token. Le grant de code d’autorisation comprend un appel d’API supplémentaire pour échanger le code contre un jeton, ce qui peut entraîner une latence inutile si tout ce dont vous avez besoin est l’ID Token. Dans bien des cas, le [flux hybride](/docs/fr-ca/get-started/authentication-and-authorization-flow/hybrid-flow) est mis en œuvre pour offrir un accès optimal à l’ID Token tout en tirant parti du flux de travail du grant de code d’autorisation pour récupérer les jetons d’accès et les Refresh Tokens de façon sécuritaire.

<Warning>
  Bien qu’Auth0 prenne en charge l’utilisation du grant implicite pour les applications s’exécutant dans le navigateur qui n’ont besoin que d’un ID Token, il est recommandé d’utiliser le grant de code d’autorisation avec [PKCE](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce). Pour en savoir plus, consultez [OAuth2 Implicit Grant and SPA](https://auth0.com/blog/oauth2-implicit-grant-and-spa/) sur le blogue Auth0.

  Si vous avez besoin d’un [Refresh Token](/docs/fr-ca/secure/tokens/refresh-tokens) afin d’obtenir un nouveau jeton d’accès ou ID Token sans que l’utilisateur ait à s’authentifier de nouveau, vous devez utiliser le [grant de code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow/call-your-api-using-the-authorization-code-flow).
</Warning>

<div id="attack-protection">
  ## Protection contre les attaques
</div>

Les systèmes d’authentification sont essentiels, car ils empêchent les <Tooltip tip="Acteurs malveillants : entité (une personne ou un groupe) qui représente une menace pour l’entreprise ou l’environnement avec l’intention de causer du tort." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=bad+actors">acteurs malveillants</Tooltip> d’accéder aux applications et aux données des utilisateurs auxquelles ils ne devraient pas avoir accès. Nous voulons multiplier les obstacles entre ces acteurs malveillants et l’accès à nos systèmes. L’une des façons les plus simples d’y parvenir est de vous assurer que votre [protection contre les attaques](/docs/fr-ca/secure/attack-protection) avec Auth0 est correctement configurée. Prenez donc un moment pour consulter les recommandations à ce sujet et vérifier qu’elle fonctionne comme prévu dans votre cas.

<Info>
  ### Bonne pratique

  La détection des anomalies est gérée en arrière-plan par Auth0 et constitue une excellente fonctionnalité de sécurité pour votre produit. Si vous comptez l’utiliser, assurez-vous d’avoir configuré votre [fournisseur de courriel](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/operations#email-provider-setup) et vos [modèles de courriel](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/branding#email-template-customization) avant d’activer l’envoi de courriels à vos utilisateurs.
</Info>

<div id="sso-with-legacy-systems">
  ## SSO avec des systèmes existants
</div>

Dans le cadre d’une restructuration à grande échelle, il n’est pas toujours possible — ni pratique — de mettre à jour toutes vos applications en même temps. En fait, la bonne pratique que nous recommandons consiste à adopter une approche itérative pour l’intégration avec Auth0. Si vos applications utilisent déjà l’authentification unique (SSO) et que votre système d’identité existant prend en charge des protocoles comme OIDC ou <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>, vous avez quelques options si vous souhaitez continuer d’offrir le SSO pendant votre intégration avec Auth0 :

* Mettez à jour votre fournisseur d’identité actuel dans votre système SSO existant afin qu’il redirige vers Auth0 pour la connexion (p. ex., en utilisant [SAML](/docs/fr-ca/authenticate/single-sign-on/outbound-single-sign-on/configure-auth0-saml-identity-provider)), ou
* Configurez Auth0 pour qu’il redirige vers votre système SSO existant pour la connexion. Cela exige de configurer votre système existant comme IdP dans Auth0 (c.-à-d. en utilisant soit [SAML](/docs/fr-ca/authenticate/protocols/saml/saml-sso-integrations/configure-auth0-saml-service-provider) soit [OIDC](/docs/fr-ca/authenticate/identity-providers/social-identity-providers)).

<Info>
  ### Bonne pratique

  Prendre en charge une expérience SSO avec votre système existant peut ajouter de la complexité, mais cela peut valoir la peine pour offrir une expérience utilisateur plus fluide pendant votre intégration avec Auth0. Si vous envisagez cette avenue, le fait de la planifier tôt peut aider à en assurer la faisabilité. Si vous n’avez pas déjà de SSO dans un service centralisé, il est peu probable que la complexité nécessaire pour l’ajouter en vaille les bénéfices.
</Info>

Il s’agit d’un sujet complexe qui exigera probablement une analyse plus approfondie selon votre architecture existante actuelle, et nous vous recommandons de ne l’examiner que si votre système existant prend déjà en charge le SSO. Remarque : si, actuellement, vos applications redirigent vers un système centralisé pour authentifier vos utilisateurs et que ce système ne demande des informations d’identification que si vous n’avez pas déjà de session avec lui, alors vous disposez d’une implémentation SSO existante.

<div id="social-authentication">
  ## Authentification sociale
</div>

Le scénario « apportez votre propre identité » offert par Facebook, Google, etc., est un excellent moyen de simplifier l’expérience d’authentification des utilisateurs sans compromettre la sécurité, et l’utilisation de [Universal Login](#universal-login) facilite l’ajout de la prise en charge des [Connexions sociales](/docs/fr-ca/authenticate/identity-providers/social-identity-providers) avec un minimum de perturbations.

<Warning>
  Auth0 offre une façon simple de tester les connexions sociales à l’aide de [clés de développeur préconfigurées](/docs/fr-ca/authenticate/identity-providers/social-identity-providers/devkeys). Cependant, elles comportent des [limites](/docs/fr-ca/authenticate/identity-providers/social-identity-providers/devkeys#limitations-of-developer-keys), et avant de passer en production, vous devrez configurer vos propres clés pour votre application en suivant les [instructions](/docs/fr-ca/authenticate/identity-providers/social-identity-providers) du ou des fournisseurs sociaux que vous avez choisis.
</Warning>

Grâce à la prise en charge de [sociale](https://auth0.com/learn/social-login/), les identités des utilisateurs et les informations d’authentification sont gérées par le fournisseur social, tout comme certaines claims d’identité, qu’Auth0 utilisera pour renseigner le [profil](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/profile-management) de l’utilisateur. Auth0 peut aussi fournir l’accès aux [jetons d’accès](/docs/fr-ca/secure/tokens/access-tokens) des fournisseurs d’identité sociale (IdP sociaux), afin que votre application puisse aussi effectuer des requêtes vers les API d’IdP sociaux tiers au nom de l’utilisateur.

<Info>
  ### Pratique exemplaire

  Social est une excellente fonctionnalité à offrir, mais lorsque vous proposez plus d’une façon de se connecter, vous devez tenir compte de la possibilité que vos clients en utilisent réellement plus d’une. Par défaut, chaque identité d’utilisateur dans Auth0 possède son propre profil d’utilisateur; vous voudrez donc probablement envisager la capacité d’Auth0 à [lier des comptes d’utilisateur](/docs/fr-ca/manage-users/user-accounts/user-account-linking) afin d’associer efficacement un même profil d’utilisateur à plusieurs identités.
</Info>

L’[extension Custom Social Connections](/docs/fr-ca/authenticate/identity-providers/social-identity-providers) d’Auth0 pousse l’authentification sociale encore plus loin en vous permettant de vous connecter à tout fournisseur tiers compatible avec [OpenID Connect (OIDC)](/docs/fr-ca/authenticate/protocols/openid-connect-protocol) qui n’est pas pris en charge d’emblée. Par exemple, la prise en charge du fournisseur d’identité gouvernementale [SwissID](https://www.swissid.ch/) peut être configurée dans Auth0 au moyen d’une connexion sociale personnalisée.

<div id="multi-factor-authentication-mfa">
  ## Authentification multifacteur (MFA)
</div>

À une époque où l’utilisation abusive des informations d’authentification des utilisateurs atteint des sommets, protéger vos systèmes représente un véritable défi, surtout alors qu’il est devenu si courant que des pirates volent les renseignements d’identité des utilisateurs. L’un des moyens les plus efficaces consiste toutefois à offrir aux utilisateurs la possibilité de configurer un second facteur pour protéger leur compte, ce qu’on appelle plus couramment l’[Authentification multifacteur](/docs/fr-ca/secure/multi-factor-authentication). Cela garantit que seul un utilisateur légitime peut accéder à son compte, même s’il utilise un nom d’utilisateur et mot de passe qui a pu être compromis dans une autre application.

<Info>
  ### Bonne pratique

  Il est assez courant que les applications destinées aux clients offrent aux utilisateurs une *option* d’ajouter un second facteur plutôt que de les *obliger* à en utiliser un. Pour en savoir plus à ce sujet, consultez [providing your users with an option to add MFA](https://auth0.com/learn/multifactor-authentication-customers/).
</Info>

Auth0 prend en charge plusieurs options pour activer la MFA afin de protéger l’accès aux comptes d’utilisateur, et plusieurs pratiques permettent de vous assurer d’offrir une protection par second facteur à la fois souple et efficace :

* Auth0 [Guardian](https://auth0.com/multifactor-authentication) : un service qui fournit à la fois la génération de notifications Push et une application permettant d’autoriser ou de rejeter des requêtes. Push envoie une notification à l’appareil préenregistré d’un utilisateur — généralement un téléphone mobile ou une tablette — à partir duquel l’utilisateur peut immédiatement autoriser ou rejeter l’accès au compte en appuyant simplement sur un bouton.
* Mot de passe à usage unique basé sur le temps ([TOTP](https://auth0.com/blog/from-theory-to-practice-adding-two-factor-to-node-dot-js/)) : vous permet d’enregistrer un appareil — comme Google Authenticator — qui générera un mot de passe à usage unique changeant au fil du temps et pouvant être saisi comme second facteur pour valider le compte d’un utilisateur.
* SMS : pour envoyer un code à usage unique par SMS, que l’utilisateur est ensuite invité à saisir avant de pouvoir terminer l’authentification.
* Voice : pour transmettre un code à usage unique par appel téléphonique, que l’utilisateur est ensuite invité à saisir avant de pouvoir terminer l’authentification.
* Duo : vous permet d’utiliser votre compte Duo pour l’authentification multifacteur.
* Email : vous permet d’utiliser votre compte de courriel pour l’authentification multifacteur.

Bien que le workflow de MFA utilisant des technologies comme Guardian ou Google Authenticator soit généralement offert au moyen d’une application distincte exécutée sur un appareil mobile ou une tablette, si vous ne voulez pas que vos clients aient à télécharger une application distincte, Auth0 vous fournit également un [SDK](https://auth0.com/blog/announcing-guardian-whitelabel-sdk/) que vous pouvez utiliser pour intégrer le workflow du second facteur directement dans vos applications mobiles existantes.

<div id="project-planning-guide">
  ## Guide de planification de projet
</div>

Nous fournissons un guide de planification au format PDF que vous pouvez télécharger et consulter pour en savoir plus sur les stratégies que nous recommandons.

[Guide de planification de projet B2C IAM](https://assets.ctfassets.net/cdy7uua7fh8z/3er1aEQ7Ul0q3c9leJWczR/b1f18b4c16abb7e78b01e4eb2b52bb8e/B2C_Project_Planning.pdf)