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

> Découvrez comment les sessions Auth0 peuvent vous aider à gérer le statut d’authentification de vos utilisateurs.

# Sessions

Une session est un ensemble d’interactions entre un utilisateur et une application pendant une période donnée. Une même session peut comprendre plusieurs activités (comme des affichages de pages, des événements, des interactions sociales et des transactions de commerce électronique) et stocker temporairement ces informations tant que l’utilisateur est connecté.

Dans une mise en œuvre standard de l’en-tête Set-Cookie, une session prend fin lorsqu’un utilisateur quitte un site Web ou ferme son navigateur. Pour éviter que les utilisateurs aient à se connecter chaque fois, les applications peuvent prolonger les sessions en définissant une durée de vie maximale pour le <Tooltip tip="Cookie de session : entité qui, lorsqu’elle est présente, permet de considérer l’utilisateur comme authentifié." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=session+cookie">cookie de session</Tooltip>. Les sessions prennent fin lorsqu’un utilisateur se déconnecte ou que la limite de durée de vie de la session est atteinte.

Pour en savoir plus, consultez la [Politique de confidentialité et sur les cookies d’Auth0](https://auth0.com/privacy).

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

Auth0 maintient une session de connexion pour tout utilisateur qui s’authentifie au moyen d’une application. Lorsqu’un utilisateur effectue une nouvelle connexion standard, Auth0 réinitialise cette session de connexion. La mise à jour d’un mot de passe, d’une adresse courriel, d’un numéro de téléphone ou d’un nom d’utilisateur entraîne aussi l’expiration de la session Auth0 de l’utilisateur.

Lorsque vous créez une application nécessitant une authentification, vous pouvez utiliser les sessions pour déterminer si un utilisateur est authentifié chaque fois qu’une requête est effectuée. Selon la façon dont votre application a été conçue, différents <Tooltip tip="Flux d’autorisation : mécanisme d’autorisation (ou workflow) précisé dans le framework OAuth 2.0." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=authorization+flows">flux d’autorisation</Tooltip> sont recommandés afin d’offrir aux utilisateurs une expérience plus sécurisée.

Par exemple, prenons un site Web conforme à OIDC (<Tooltip tip="OpenID : norme ouverte d’authentification qui permet aux applications de vérifier l’identité des utilisateurs sans recueillir ni stocker les informations de connexion." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OpenID">OpenID</Tooltip> Connect) appelé storezero.io.

<Frame>
  <img src="https://mintcdn.com/translations/MV7tE-x71x8RWRES/docs/images/cdy7uua7fh8z/5XXxdX4fuApQtAapQfZU1b/2fd9161af60962e3de3fc951d95b83d1/use-case-storezero.png?fit=max&auto=format&n=MV7tE-x71x8RWRES&q=85&s=acce140587a28a365274a86cf166a879" alt="Exemple de site Web de commerce électronique Storezero.io" width="889" height="987" data-path="docs/images/cdy7uua7fh8z/5XXxdX4fuApQtAapQfZU1b/2fd9161af60962e3de3fc951d95b83d1/use-case-storezero.png" />
</Frame>

Storezero.io n’exige pas que ses utilisateurs se connectent pour effectuer des achats. Toutefois, ils doivent se connecter pour consulter la section Mon compte du site.

Pour les cas d’utilisation présentés ci-dessous, prenons le scénario où un utilisateur souhaite consulter ses commandes précédentes avant de passer à la caisse. Pour ce faire, il accède à la page Toutes les commandes de la section Mon compte et est invité à se connecter.

<div id="login-flows">
  ### Flux de connexion
</div>

La plupart des types d’applications (comme les applications Web, les applications monopage et les applications natives) devraient utiliser le [flux de code d’autorisation avec PKCE](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) pour l’authentification à la connexion. Ce flux consiste à échanger un code d’autorisation contre des jetons.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Le flux de code d’autorisation avec PKCE remplace l’ancien usage du flux implicite pour les applications monopage sans backend. Tout nouveau développement doit utiliser ce flux afin d’assurer une sécurité optimale. Il est également fortement recommandé de migrer les applications existantes qui utilisent le flux implicite vers le flux de code d’autorisation avec PKCE.
</Callout>

<div id="user-logs-in-with-username-and-password">
  #### L’utilisateur se connecte avec son nom d’utilisateur et son mot de passe
</div>

Dans cet exemple, un utilisateur se connecte manuellement à l’aide de son nom d’utilisateur et de son mot de passe :

1. Le SDK d’Auth0 crée une session locale et redirige l’utilisateur vers le serveur d’autorisation Auth0 (point de terminaison `/authorize`).
2. Le serveur d’autorisation crée une session, puis redirige l’utilisateur vers le prompt de connexion et d’autorisation.
3. L’utilisateur s’authentifie à l’aide de son nom d’utilisateur et de son mot de passe.
4. Le serveur d’autorisation Auth0 met à jour la session de l’utilisateur créée précédemment pour indiquer qu’il est connecté.
5. Selon le flux utilisé, le serveur d’autorisation renvoie l’utilisateur à votre application, avec soit un ID token, soit un code d’autorisation.
6. Votre application échange le token ou le code d’autorisation contre un jeton d’accès et termine le flux.

Avec ce flux, deux sessions sont créées :

* La **session locale** (storezero.io), qui indique à l’application si un utilisateur est authentifié.
* La **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="/docs/fr-ca/glossary?term=authorization+server">serveur d’autorisation</Tooltip>** (storezero.auth0.com), qui indique au serveur si un utilisateur est authentifié. La session du serveur peut aussi, de façon facultative, suivre certains détails liés à l’authentification.

  * Par exemple, le serveur d’autorisation peut suivre si un utilisateur a eu recours à l’[authentification multifacteur (MFA)](/docs/fr-ca/secure/multi-factor-authentication). Cette information peut ensuite servir à déterminer si l’utilisateur devra se connecter ou utiliser l’authentification multifacteur la prochaine fois qu’il arrivera au serveur d’autorisation.

<div id="user-logs-in-with-identity-provider">
  #### L’utilisateur se connecte avec un fournisseur d’identité
</div>

Dans cet exemple, l’utilisateur choisit de se connecter avec Facebook plutôt qu’avec son nom d’utilisateur et son mot de passe :

1. Le SDK d’Auth0 crée une session locale et redirige l’utilisateur vers le serveur d’autorisation Auth0 (point de terminaison `/authorize`).
2. Le serveur d’autorisation crée une session, puis redirige l’utilisateur vers le prompt de connexion et d’autorisation.
3. Lorsqu’il choisit de se connecter avec Facebook, le serveur d’autorisation redirige l’utilisateur vers Facebook.
4. Facebook crée une session et authentifie l’utilisateur. Facebook met ensuite à jour sa session pour indiquer que l’utilisateur est connecté.
5. Facebook renvoie l’utilisateur vers le serveur d’autorisation Auth0. Le serveur d’autorisation met ensuite à jour sa session pour indiquer que l’utilisateur est connecté.
6. Selon le flux utilisé, le serveur d’autorisation renvoie l’utilisateur vers votre application, avec soit un ID token, soit un code d’autorisation.
7. Votre application échange le token ou le code d’autorisation contre un jeton d’accès et termine le flux.

Dans ce scénario, trois sessions sont créées : la **session locale** (storezero.io), la **session du serveur d’autorisation** (storezero.auth0.com) et une **session du <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+provider">fournisseur d’identité</Tooltip> (IdP)** (facebook.com).

La session IdP sur le serveur de Facebook authentifie l’utilisateur et offre une expérience <Tooltip tip="Single Sign-On (SSO) : Service qui, après qu’un utilisateur s’est connecté à une application, connecte automatiquement cet utilisateur à d’autres applications." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=SSO">SSO</Tooltip> fluide. Comme il est très probable que les utilisateurs soient déjà connectés à Facebook, ils sont souvent authentifiés sans avoir à saisir manuellement leurs informations d’authentification Facebook.

<div id="session-management-for-spas">
  ### Gestion des sessions pour les SPA
</div>

Dans les exemples précédents, une session locale est créée lorsque l’utilisateur lance l’un ou l’autre des processus de connexion. Cette session locale peut garder les utilisateurs connectés et déterminer à quel moment ils doivent s’authentifier de nouveau.

Cependant, les sessions locales ne sont pas offertes pour les applications sans backend, comme les applications monopages (SPA). Ces applications utilisent plutôt une autre approche, appelée [authentification silencieuse](/docs/fr-ca/authenticate/login/configure-silent-authentication), pour garder les utilisateurs connectés.

L’authentification silencieuse utilise la session sur le serveur d’autorisation pour déterminer quand un utilisateur doit s’authentifier de nouveau. Un iframe caché redirige les requêtes d’authentification vers le serveur d’autorisation avec le paramètre `prompt=none`. Ce paramètre empêche le serveur de demander une saisie à l’utilisateur.

* Si la session sur le serveur d’autorisation n’a pas expiré, la transaction se poursuit sans interruption. Le serveur envoie un <Tooltip tip="Jeton d’accès : 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> par l’entremise de WMRM (Web Message Response Mode), qui utilise `postMessage`.
* Si la session sur le serveur d’autorisation a expiré ou si l’utilisateur se déconnecte, la redirection dans l’iframe renvoie une erreur. L’application doit alors rediriger l’utilisateur vers le serveur d’autorisation pour qu’il s’authentifie de nouveau.

<div id="learn-more">
  ## En savoir plus
</div>

* [Niveaux de session](/docs/fr-ca/manage-users/sessions/session-layers)
* [Limites de durée de vie de la session](/docs/fr-ca/manage-users/sessions/session-lifetime-limits)
* [Configurer les paramètres de durée de vie de la session](/docs/fr-ca/manage-users/sessions/configure-session-lifetime-settings)
* [Cookies](/docs/fr-ca/manage-users/cookies)
* [Modifications apportées à l’attribut SameSite des cookies](/docs/fr-ca/manage-users/cookies/samesite-cookie-attribute-changes)
* [Authentifier les applications monopages avec des cookies](/docs/fr-ca/manage-users/cookies/spa-authenticate-with-cookies)