Configurer l’authentification silencieuse

Découvrez comment garder les utilisateurs connectés à votre application à l’aide de l’authentification silencieuse.

Le protocole OpenID Connect prend en charge un paramètre prompt=none sur la demande d’authentification qui permet aux applications d’indiquer que le serveur d’autorisation ne doit afficher aucune interaction utilisateur (telle que l’authentification, le consentement ou la MFA). Auth0 renverra soit la réponse demandée à l’application, soit une erreur si l’utilisateur n’est pas déjà authentifié ou si un type de consentement ou d’invite est requis avant de continuer.

L’utilisation du flux implicite dans les applications Web monopages soulève des problèmes de sécurité qui doivent être résolus par des mesures correctives explicites. Vous pouvez utiliser le Flux de code d’autorisation avec PKCE en conjonction avec l’authentification silencieuse pour renouveler les sessions dans les applications Web monopages.

Les progrès récents en matière de contrôle de la vie privée dans les navigateurs ont un impact négatif sur l’expérience de l’utilisateur en empêchant l’accès aux témoins tiers; par conséquent, les flux basés sur les navigateurs doivent utiliser la Rotation des jetons d’actualisation, qui offre une méthode sécurisée pour utiliser les jetons d’actualisation dans les SPA, tout en fournissant un accès intégré aux ressources sans interruption dans l’expérience utilisateur causée par les technologies de confidentialité comme ITP.

​

Lancer des demandes d’authentification silencieuse

Pour lancer une demande d’authentification silencieuse, ajoutez le paramètre prompt=none lorsque vous redirigez un utilisateur vers le point de terminaison /authorize d’Authentication API Auth0. (Les paramètres individuels de la demande d’authentification varient en fonction des besoins particuliers de votre application.)

Par exemple :

GET https://{yourDomain}/authorize
    ?response_type=id_token token&
    client_id=...&
    redirect_uri=...&
    state=...&
    scope=openid...&
    nonce=...&
    audience=...&
    response_mode=...&
    prompt=none

Le paramètre prompt=none oblige Auth0 à envoyer immédiatement un résultat à la redirection_uri (URL de rappel) indiquée, en utilisant le response_mode indiqué, avec l’une des deux réponses possibles : réussite ou erreur.

Toutes les règles applicables seront exécutées dans le cadre du processus d’authentification silencieuse.

​

Réponses d’authentification réussie

Si l’utilisateur était déjà connecté à Auth0 et qu’aucune autre invite interactive n’est requise, Auth0 répondra exactement comme si l’utilisateur s’était authentifié manuellement à partir de la page de connexion.

Par exemple, lors de l’utilisation du flux implicite (response_type=id_token jeton, utilisé pour les applications à page unique), Auth0 répondra avec les jetons demandés :

GET {https://yourApp/callback}
    #id_token=...&
    access_token=...&
    state=...&
    expires_in=...

Cette réponse est indiscernable d’une connexion effectuée directement sans le paramètre prompt=none.

​

Réponses d’erreur

Si l’utilisateur n’est pas connecté via l’authentification unique (SSO) ou si sa session SSO a expiré, Auth0 le redirigera vers la redirection_uri (URL de rappel) en affichant une erreur :

GET https://your_callback_url/
    #error=ERROR_CODE&
    error_description=ERROR_DESCRIPTION&
    state=...

Les valeurs possibles pour ERROR_CODE sont définies par les Spécifications OpenID Connect :

Réponse	Description
login_required	L’utilisateur n’était pas connecté à Auth0, donc l’authentification silencieuse n’est pas possible. Cette erreur peut se produire en fonction de la configuration des paramètres Log In Session Management (Gestion de session de connexion) au niveau du locataire; en particulier, elle peut se produire après la période définie dans le paramètre Require log in after (Exiger la connexion après). Consultez Configuration des paramètres de durée de vie des sessions pour plus de détails.
consent_required	L’utilisateur a été connecté à Auth0, mais doit donner son consentement pour autoriser l’application.
interaction_required	L’utilisateur était connecté à Auth0 et a autorisé l’application, mais doit être redirigé ailleurs avant que l’authentification puisse être terminée; par exemple, lors de l’utilisation d’une règle de redirection.

Si l’une de ces erreurs est renvoyée, l’utilisateur doit être redirigé vers la page de connexion Auth0 sans le paramètre prompt=none à authentifier.

​

Renouveler les jetons expirés

Vous pouvez effectuer une demande d’authentification silencieuse pour obtenir de nouveaux jetons tant que l’utilisateur dispose toujours d’une session valide sur Auth0. La méthode checkSessionde auth0.js utilise une requête de jeton silencieuse en combinaison avec response_mode=web_message pour les application Web monopages afin que la requête se produise dans un iframe caché. Avec les application Web monopages, Auth0.js gère le traitement des résultats (soit le jeton, soit le code d’erreur) et transmet les informations à l’aide d’une fonction de rappel fournie par l’application. Cela n’entraîne aucune perturbation de l’expérience utilisateur (pas d’actualisation de page ni de perte d’état).

Consultez Renouvellement des jetons avec Safari pour d’autres limitations importantes et des solutions de contournement avec le navigateur Safari.

​

Expiration du jeton d’accès

Les jetons d’accès sont opaques pour les applications. Cela signifie que les applications ne peuvent pas inspecter le contenu des jetons d’accès pour déterminer leur date d’expiration.

Il existe deux façons de déterminer la date d’expiration d’un jeton d’accès :

• Lisez le paramètre de réponse expires_in renvoyé par Auth0.
• Ignorez complètement les dates d’expiration. Renouveler plutôt le jeton d’accès si votre API rejette une demande de l’application (par exemple avec un code d’erreur 401).

Dans le cas d’un Flux implicite, le paramètre expires_in est renvoyé par Auth0 sous forme de paramètre de hachage suite à une authentification réussie. Dans le Flux de code d’autorisation avec PKCE, il est renvoyé au serveur dorsal lors de l’exécution de l’échange de code d’autorisation.

Le paramètre expires_in indique combien de secondes le jeton d’accès sera valide et peut être utilisé pour anticiper l’expiration du jeton d’accès.

​

Réponses d’erreur

Vous pourriez recevoir une réponse d’erreur de type timeout, indiquant que le délai d’exécution de la communication web_message s’est écoulé. Cette erreur est généralement associée à un retour à l’authentification cross-origin. Pour résoudre ce problème, assurez-vous d’ajouter toutes les URL à partir desquelles vous souhaitez effectuer une authentification silencieuse dans le champ Origines Web autorisées pour votre application à l’aide d’Auth0 Dashboard.

​

Interroger avec checkSession()

Dans certains scénarios multi-applications où la déconnexion unique est souhaitée (c’est-à-dire qu’un utilisateur se déconnectant d’une application doit également être déconnecté des autres applications), une application peut être configurée pour interroger périodiquement Auth0 en utilisant checkSession() pour voir si une session existe. Si la session n’existe pas, vous pouvez alors déconnecter l’utilisateur de l’application. La même méthode d’interrogation peut être mise en place pour une authentification silencieuse dans un scénario d’authentification unique (SSO).

L’intervalle d’interrogation entre les vérifications de checkSession() devrait être d’au moins 15 minutes entre chaque appel pour éviter tout problème ultérieur lié à la limite anti-attaques de cet appel.

​

Authentification silencieuse avec l’authentification multifacteur (MFA)

Dans certaines situations, vous pourriez ne pas vouloir demander à l’utilisateur d’avoir recours à l’Authentification multifacteur (MFA) chaque fois qu’il se connecte à partir du même navigateur. Pour ce faire, configurez une action afin que la MFA ne se produise qu’une seule fois par session. Ceci est utile lors de l’exécution d’une authentification silencieuse (prompt=none) pour renouveler les jetons d’accès de courte durée dans une application Web monopage pendant la durée de la session d’un utilisateur sans avoir à définir le paramètre allowRememberBrowser sur true (vrai).

exports.onExecutePostLogin = async (event, api) => {
  const authMethods = event.authentication?.methods || []

  const completedMfa = !!authMethods.find((method) => method.name === 'mfa')

  if (!completedMfa) {
    api.multifactor.enable('any', { allowRememberBrowser: true })
  }
};

Pour en savoir plus, veuillez consulter Modifier la fréquence des demandes d’authentification.

​

En savoir plus

• Rotation des jetons d’actualisation
• Configurer la rotation des jetons d’actualisation
• Dépannage des erreurs de jeton non valide
• Vérifier les appels d’API
• Dépannage des problèmes d’authentification multifacteur (MFA)