Sessions

Une session est un groupe d’interactions entre un utilisateur et une application pendant une période donnée. Une session unique peut consister en plusieurs activités (telles que la consultation de pages, des événements, des interactions sociales et des transactions de commerce électronique) et peut stocker temporairement ces informations pendant que l’utilisateur est connecté.

Avec une implémentation standard de l’en-tête Set-Cookie, une session se termine lorsque l’utilisateur quitte un site web ou ferme son navigateur. Pour éviter que les utilisateurs n’aient à se connecter à chaque fois, les applications peuvent prolonger les sessions en définissant une durée de vie maximale pour le témoin de session. Les sessions se terminent lorsque l’utilisateur se déconnecte ou que la limite de durée de vie de la session est atteinte.

Pour en savoir plus, consultez Politique d’Auth0 en matière de confidentialité et de témoins.

Auth0 maintient une session de connexion pour tout utilisateur qui s’authentifie par le biais 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’une adresse courriel ou d’un numéro de téléphone entraîne également l’expiration de la session Auth0 d’un utilisateur.

Lorsque vous créez une application nécessitant une authentification, vous pouvez utiliser des sessions pour déterminer si un utilisateur est authentifié à chaque fois qu’une demande est formulée. En fonction de la façon par laquelle votre application a été construite, différents flux d’autorisation sont recommandés pour offrir une expérience plus sûre aux utilisateurs.

Prenons l’exemple d’un site web conforme à l’OIDC (OpenID Connect) appelé storezero.io.

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

Pour les cas d’utilisation énumérés ci-dessous, considérons un scénario dans lequel un utilisateur souhaite consulter ses commandes précédentes avant de passer à la caisse. Pour ce faire, il se rend sur la page Toutes les commandes de la section Mon compte et est invité à se connecter.

La plupart des types d’applications (telles que les applications web, les applications à page unique et les applications natives) devraient utiliser le Flux de code d’autorisation avec PKCE pour faciliter l’authentification de la connexion. Ce flux implique l’échange d’un code d’autorisation contre des jetons.

Dans cet exemple, un utilisateur se connecte manuellement en utilisant son nom d’utilisateur et son mot de passe :

1. La trousse SDK 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 Auth0 met à jour la session précédemment créée par l’utilisateur pour indiquer qu’il est connecté.

5. En fonction du flux utilisé, le serveur d’autorisation renvoie l’utilisateur à votre application, avec un jeton d’ID ou 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), laquelle indique à l’application si un utilisateur est authentifié.

• La session du serveur d’autorisation (storezero.auth0.com), qui indique au serveur si un utilisateur est authentifié. La session du serveur peut également suivre les détails de l’authentification (facultatif).

  • Par exemple, le serveur d’autorisation peut savoir si un utilisateur a utilisé l’authentification multifacteur (MFA). Ces informations peuvent ensuite être utilisées pour déterminer si un utilisateur doit être invité à se connecter ou à utiliser la MFA lors de sa prochaine visite au serveur d’autorisation.

Dans cet exemple, l’utilisateur choisit de se connecter avec Facebook au lieu de son nom d’utilisateur et de son mot de passe :

1. La trousse SDK 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. Si l’utilisateur choisit de se connecter avec Facebook, le serveur d’autorisation le redirige vers Facebook.

4. Le serveur d’autorisation de 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 au serveur d’autorisation Auth0. Le serveur d’autorisation met alors à jour sa session pour indiquer que l’utilisateur est connecté.

6. En fonction du flux utilisé, le serveur d’autorisation renvoie l’utilisateur à votre application, avec un jeton d’ID ou un code d’autorisation.

7. Votre application échange le jeton 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 fournisseur d’identité (IdP) (facebook.com).

La session de l’IdP sur le serveur de Facebook authentifie l’utilisateur et fournit une expérience SSO transparente. Comme il est très probable que les utilisateurs soient déjà connectés à Facebook, ils sont souvent authentifiés sans avoir à fournir manuellement leurs informations d’identification Facebook.

Dans les exemples précédents, une session locale est créée lorsque l’utilisateur initie l’un ou l’autre flux de connexion. Cette session locale permet aux utilisateurs de rester connectés et de déterminer quand ils doivent se réauthentifier.

Cependant, les sessions locales ne sont pas disponibles pour les applications sans système dorsal, telles que les applications à page unique. Au lieu de cela, ces applications utilisent une approche différente connue sous le nom d’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. Une iframe cachée redirige les demandes d’authentification vers le serveur d’autorisation avec le paramètre prompt=none. Ce paramètre empêche le serveur de demander à l’utilisateur d’entrer des données.

• Si la session sur le serveur d’autorisation n’a pas expiré, la transaction se poursuit sans interruption. Le serveur envoie un jeton d’accès par l’intermédiaire du WMRM (Web Message Response Mode), qui utilise postMessage.

• Si la session sur l’autorisation a expiré ou si l’utilisateur se déconnecte, la redirection dans l’iframe renvoie une erreur. L’application doit alors diriger l’utilisateur vers le serveur d’autorisation pour une nouvelle authentification.

• Couches de sessions
• Limites de durée de vie des sessions
• Configuration des paramètres de durée de vie des sessions
• Témoins
• Modifications des attributs du témoin SameSite
• Authentifier les applications à page unique avec des témoins