Skip to main content
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 . 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.

​
Cas d’utilisation des sessions

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 sont recommandés afin d’offrir aux utilisateurs une expérience plus sécurisée. Par exemple, prenons un site Web conforme à OIDC ( Connect) appelé storezero.io.
Exemple de site Web de commerce électronique Storezero.io
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.

​
Flux de connexion

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 pour l’authentification à la connexion. Ce flux consiste à échanger un code d’autorisation contre des jetons.
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.

​
L’utilisateur se connecte avec son nom d’utilisateur et son mot de passe

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 (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). 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.

​
L’utilisateur se connecte avec un fournisseur d’identité

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 (IdP) (facebook.com). La session IdP sur le serveur de Facebook authentifie l’utilisateur et offre une expérience 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.

​
Gestion des sessions pour les SPA

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

​
En savoir plus