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 modification 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 également 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 flux d’autorisation sont recommandés pour offrir une expérience plus sécuritaire aux utilisateurs. Prenons par exemple un site Web conforme à OIDC (OpenID Connect) appelé storezero.io. Storezero.io n’exige pas que ses utilisateurs se connectent pour effectuer des achats. Ils doivent toutefois se connecter pour consulter la section Mon compte du site. Pour les cas d’utilisation présentés ci-dessous, imaginons qu’un utilisateur souhaite consulter ses commandes précédentes avant de finaliser son achat. Pour ce faire, il accède à la page Toutes les commandes de la section Mon compte, où il est invité à se connecter.

​

Flux de connexion

La plupart des types d’applications (comme les applications Web, les applications monopages et les applications natives) devraient utiliser le flux de code d’autorisation avec PKCE pour authentifier les utilisateurs lors de la connexion. Ce flux consiste à échanger un code d’autorisation contre des jetons.

​

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

Dans cet exemple, un utilisateur se connecte manuellement 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 d’Auth0 (terminal /authorize).
2. Le serveur d’autorisation crée une session, puis redirige l’utilisateur vers l’écran de connexion et d’autorisation.
3. L’utilisateur s’authentifie avec son nom d’utilisateur et 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 redirige l’utilisateur vers votre application et lui transmet soit un jeton d’ID, 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.

Ce flux crée deux sessions :

• La session locale (storezero.io), qui 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 aussi conserver des renseignements sur l’authentification.
  • Par exemple, le serveur d’autorisation peut enregistrer si un utilisateur a eu recours à l’authentification multifacteur (MFA). Cette information peut ensuite servir à déterminer s’il faut inviter l’utilisateur à 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 d’Auth0 (terminal /authorize).
2. Le serveur d’autorisation crée une session, puis redirige l’utilisateur vers l’écran de connexion et d’autorisation.
3. Lorsque l’utilisateur choisit de se connecter avec Facebook, le serveur d’autorisation le redirige vers Facebook.
4. Facebook crée une session et authentifie l’utilisateur, puis met à jour sa session pour indiquer qu’il est connecté.
5. Facebook renvoie l’utilisateur au serveur d’autorisation d’Auth0, qui met à jour sa session pour indiquer qu’il est connecté.
6. Selon le flux utilisé, le serveur d’autorisation renvoie l’utilisateur vers 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, ce qui 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 IdP sur le serveur de Facebook authentifie l’utilisateur et lui offre une expérience d’authentification unique (SSO) fluide. Puisque les utilisateurs sont souvent déjà connectés à Facebook, ils peuvent généralement être authentifiés sans avoir à saisir leurs informations d’identification Facebook.

​

Gestion des sessions pour les applications monopages

Dans les exemples précédents, une session locale est créée lorsque l’utilisateur amorce l’un ou l’autre des flux de connexion. Elle permet aux utilisateurs de rester connectés et de déterminer à quel moment ils doivent s’authentifier de nouveau. Toutefois, les applications sans composante côté serveur, comme les applications monopages (SPA), ne peuvent pas utiliser de session locale. Elles ont plutôt recours à l’authentification silencieuse pour garder les utilisateurs connectés. L’authentification silencieuse s’appuie sur la session du serveur d’autorisation pour déterminer quand un utilisateur doit s’authentifier de nouveau. Une iframe masqué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 une intervention à l’utilisateur.

• Si la session du serveur d’autorisation n’a pas expiré, la transaction se poursuit sans interruption. Le serveur envoie un jeton d’accès au moyen de WMRM (Web Message Response Mode), qui utilise postMessage.
• Si la session du serveur d’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 qu’il s’authentifie de nouveau.