> ## 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écrit ce que sont les sessions et comment elles sont utilisées dans Auth0.

# 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 consultations de pages, des événements, des interactions sociales et des transactions de commerce électronique) et stocker temporairement ces informations pendant que l’utilisateur est connecté.

Avec une implémentation 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="/fr-CA/docs/glossary?term=session+cookie">cookie de session</Tooltip>. Les sessions prennent fin lorsqu’un utilisateur se déconnecte ou lorsque leur durée de vie maximale est atteinte.

Pour en savoir plus, consultez la [Politique de confidentialité et d’utilisation des témoins 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 la session de connexion. La mise à jour d’un mot de passe, d’un courriel, d’un numéro de téléphone ou d’un nom d’utilisateur entraîne également l’expiration de la session Auth0 de l’utilisateur.

Lorsque vous créez une application qui exige une authentification, vous pouvez utiliser des sessions pour déterminer si un utilisateur est authentifié à chaque requête. Selon la façon dont votre application a été conçue, différents <Tooltip tip="Flux d’autorisation : octroi d’autorisation (ou flux de travail) défini dans le cadre OAuth 2.0." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=authorization+flows">flux d’autorisation</Tooltip> sont recommandés afin d’offrir une expérience plus sécurisée aux utilisateurs.

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 leurs renseignements de connexion." cta="Voir le glossaire" href="/fr-CA/docs/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 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 énumérés ci-dessous, prenons le scénario d’un utilisateur qui 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, puis on lui demande de 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](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) pour l’authentification de 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’usage antérieur 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 d’Auth0 (point de terminaison `/authorize`).
2. Le serveur d’autorisation crée une session, puis redirige l’utilisateur vers l’invite 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 d’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 vers votre application, avec soit un jeton d’identité, soit un code d’autorisation.
6. Votre application échange le jeton 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="/fr-CA/docs/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, au besoin, conserver des détails sur l’authentification.

  * Par exemple, le serveur d’autorisation peut déterminer si un utilisateur a utilisé l’[authentification multifacteur (MFA)](/fr-CA/docs/secure/multi-factor-authentication). Cette information peut ensuite servir à déterminer si l’utilisateur devra être invité à se connecter ou à utiliser la MFA la prochaine fois qu’il accède 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 l’invite 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 ramène l’utilisateur vers le serveur d’autorisation Auth0. Le serveur d’autorisation met alors à 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 jeton d’identité, soit un code d’autorisation.
7. Votre application échange le jeton ou le code d’autorisation pour obtenir 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="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> (IdP)** (facebook.com).

La session IdP sur le serveur de Facebook authentifie l’utilisateur et offre une expérience de <Tooltip tip="Authentification unique (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="/fr-CA/docs/glossary?term=SSO">SSO</Tooltip> transparente. 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 identifiants Facebook.

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

Dans les exemples précédents, une session locale est créée lorsque l’utilisateur lance l’un ou l’autre des flux de connexion. Cette session locale peut maintenir la connexion des utilisateurs et déterminer à quel moment ils doivent se réauthentifier.

Cependant, les sessions locales ne sont pas disponibles pour les applications sans backend, comme les applications monopage (SPA). Ces applications utilisent plutôt une approche différente appelée [authentification silencieuse](/fr-CA/docs/authenticate/login/configure-silent-authentication) pour maintenir la connexion des utilisateurs.

L’authentification silencieuse utilise la session sur le serveur d’autorisation pour déterminer quand un utilisateur doit se réauthentifier. 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 intervention à l’utilisateur.

* Si la session sur le serveur d’autorisation n’a pas expiré, la transaction se poursuit de façon transparente. Le serveur envoie un <Tooltip tip="Jeton d’accès : information d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisée pour accéder à une API." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=access+token">jeton d’accès</Tooltip> par WMRM (Web Message Response Mode), qui s’appuie sur `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 se réauthentifie.

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

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