Passer au contenu principal
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 . 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.

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

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

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

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

​
Gestion des sessions pour les applications monopage

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

​
En savoir plus