Configurer l’authentification silencieuse

Découvrez comment maintenir la connexion des utilisateurs à votre application à l’aide de l’authentification silencieuse.

Le protocole OpenID Connect prend en charge le paramètre prompt=none dans la requête d’authentification, ce qui permet aux applications d’indiquer que le serveur d’autorisation ne doit afficher aucune interaction utilisateur (comme l’authentification, le consentement ou le 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 consentement ou une invite est requis avant de poursuivre.

L’utilisation du flux implicite dans les SPA présente des risques de sécurité qui exigent des stratégies d’atténuation explicites. Vous pouvez utiliser le flux de code d’autorisation avec PKCE conjointement avec l’authentification silencieuse pour renouveler les sessions dans les SPA.

Les récentes avancées en matière de contrôles de confidentialité dans les navigateurs nuisent à l’expérience utilisateur en empêchant l’accès aux cookies tiers; par conséquent, les flux dans le navigateur doivent utiliser la rotation des jetons d’actualisation, qui offre une méthode sécurisée pour utiliser des jetons d’actualisation dans les SPA, tout en donnant aux utilisateurs finaux un accès fluide aux ressources, sans les perturbations de l’UX causées par des technologies de confidentialité des navigateurs comme ITP.

​

Lancer des requêtes d’authentification silencieuse

Pour lancer une requête d’authentification silencieuse, ajoutez le paramètre prompt=none lorsque vous redirigez un utilisateur vers l’endpoint /authorize de l’Authentication API d’Auth0. (Les paramètres de la requête d’authentification varient selon les besoins précis de votre application.)

Par exemple :

Le paramètre prompt=none fait en sorte qu’Auth0 envoie immédiatement un résultat au redirect_uri indiqué (URL de rappel) au moyen du response_mode spécifié, avec l’une des deux réponses possibles : succès ou erreur.

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

​

Modes de réponse

Le paramètre response_mode détermine comment Auth0 transmet la réponse d’autorisation à votre application. Pour l’authentification silencieuse, vous pouvez utiliser :

Mode	Mode de livraison	Cas d’utilisation
query	Chaîne de requête (?code=...)	flux de code d’autorisation avec traitement côté serveur
fragment	Fragment d’URL (#access_token=...)	flux implicite (ancienne version)
web_message	API postMessage()	Recommandé pour les SPA - aucune navigation entre les pages n’est nécessaire

Lors de l’utilisation de web_message, Auth0 affiche une page HTML dans un iframe masqué qui utilise l’API HTML5 Web Messaging pour transmettre le résultat à votre application. Cela permet l’authentification silencieuse sans redirection visible ni perte d’état.

Pour utiliser response_mode=web_message, vous devez ajouter l’URL de votre application au champ Allowed Web Origins dans les paramètres de votre application. Pour en savoir plus sur tous les modes de réponse, consultez le framework d’autorisation OAuth 2.0.

​

Réponses d’authentification réussies

Si l’utilisateur est déjà connecté à Auth0 et qu’aucune autre étape interactive n’est requise, Auth0 répond exactement comme si l’utilisateur s’était authentifié manuellement sur la page de connexion. Le format de la réponse dépend du response_mode utilisé :

web_message

Lorsque vous utilisez response_mode=web_message avec le flux de code d’autorisation avec PKCE (response_type=code), Auth0 renvoie une page HTML qui transmet le code d’autorisation à votre application :

<script>
  window.parent.postMessage({
    type: 'authorization_response',
    response: {
      code: 'SplX...GT',
      state: 'your_state_value'
    }
  }, 'https://yourApp.com');
</script>

Votre application (ou SDK) écoute ce message et échange le code contre des jetons. Si l’utilisateur n’a pas de session valide, Auth0 renvoie plutôt une erreur :

<script>
  window.parent.postMessage({
    type: 'authorization_response',
    response: {
      error: 'login_required',
      error_description: 'Login required',
      state: 'your_state_value'
    }
  }, 'https://yourApp.com');
</script>

fragment

Lorsque vous utilisez response_mode=fragment (par défaut pour le flux implicite avec response_type=id_token token), Auth0 redirige avec les jetons dans le fragment de l’URL :

GET https://yourApp.com/callback
    #id_token=eyJhbG...&
    access_token=eyJhbG...&
    state=your_state_value&
    expires_in=86400

query

Lorsque vous utilisez response_mode=query (par défaut pour le flux de code d’autorisation avec response_type=code), Auth0 redirige avec le code dans la chaîne de requête :

GET https://yourApp.com/callback
    ?code=SplX...GT&
    state=your_state_value

Le format de ces réponses est identique à celui d’une connexion effectuée directement sans le paramètre prompt=none. La seule différence est qu’avec prompt=none, la réponse est immédiate, sans aucune interaction de l’utilisateur.

​

Réponses d’erreur

Si l’utilisateur n’était pas connecté au moyen de l’authentification unique (SSO), ou si sa session SSO avait expiré, Auth0 renvoie une erreur au moyen du même response_mode. Pour les modes basés sur la redirection (fragment ou query) :

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

Pour le mode web_message, l’erreur est transmise au moyen de postMessage(), comme dans l’exemple ci-dessus.

Les valeurs possibles de ERROR_CODE sont définies par la spécification OpenID Connect :

Réponse	Description
login_required	L’utilisateur n’était pas connecté à Auth0; l’authentification silencieuse n’est donc pas possible. Cette erreur peut se produire selon la configuration des paramètres de gestion de la session de connexion au niveau du tenant; plus précisément, elle peut survenir après la période définie par le paramètre Exiger une connexion après. Consultez Configurer les paramètres de durée de vie de la session pour en savoir plus.
consent_required	L’utilisateur était connecté à Auth0, mais il doit donner son consentement pour autoriser l’application.
interaction_required	L’utilisateur était connecté à Auth0 et a autorisé l’application, mais il 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 afin de s’authentifier.

​

Renouveler les jetons expirés

Vous pouvez effectuer une requête d’authentification silencieuse pour obtenir de nouveaux jetons tant que l’utilisateur a toujours une session valide chez Auth0. La méthode checkSession d’auth0.js utilise une requête de jeton silencieuse en combinaison avec response_mode=web_message pour les SPA, afin que la requête s’exécute dans un iframe masqué. Avec les SPA, Auth0.js traite le résultat (le jeton ou le code d’erreur) et transmet l’information au moyen d’une fonction de rappel fournie par l’application. Il n’y a donc aucune perturbation de l’expérience utilisateur (aucune actualisation de la page ni perte d’état).

​

Expiration du jeton d’accès

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

Il existe deux façons de déterminer à quel moment un jeton d’accès expire :

• Lire le paramètre de réponse expires_in renvoyé par Auth0.
• Ignorer complètement les dates d’expiration. Renouvelez plutôt le jeton d’accès si votre API rejette une requête de l’application (par exemple, avec un code 401).

Dans le cas du Flux implicite, le paramètre expires_in est renvoyé par Auth0 sous forme de paramètre de hachage après une authentification réussie. Dans le Flux de code d’autorisation avec PKCE, il est renvoyé au serveur backend lors de l’échange du code d’autorisation.

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

​

Réponse d’erreur

Vous pourriez recevoir la réponse d’erreur timeout, ce qui indique qu’un délai d’attente s’est produit pendant l’exécution de la communication web_message. Cette erreur est généralement associée au recours à l’authentification cross-origin. Pour la corriger, assurez-vous d’ajouter toutes les URL à partir desquelles vous souhaitez effectuer une authentification silencieuse dans le champ Allowed Web Origins de votre Application à l’aide du Auth0 Dashboard.

​

Interroger avec checkSession()

Dans certains scénarios impliquant plusieurs applications, où la déconnexion unique est souhaitée (si un utilisateur se déconnecte d’une application, il doit aussi être déconnecté des autres applications), une application peut être configurée pour interroger périodiquement Auth0 à l’aide de checkSession() afin de vérifier si une session existe. Si aucune session n’existe, vous pouvez alors déconnecter l’utilisateur de l’application. La même méthode d’interrogation peut être utilisée pour mettre en œuvre l’authentification silencieuse dans un scénario d’authentification unique (SSO).

L’intervalle entre les vérifications effectuées avec checkSession() devrait être d’au moins 15 minutes afin d’éviter tout problème futur lié à la limitation du débit pour cette requête.

​

Authentification silencieuse avec l’authentification multifacteur

Dans certains cas, vous pouvez vouloir éviter d’inviter l’utilisateur à effectuer l’authentification multifacteur (MFA) chaque fois qu’il se connecte à partir du même navigateur. Pour ce faire, configurez une règle afin que la MFA n’ait lieu qu’une seule fois par session. Cela est utile lors de l’authentification silencieuse (prompt=none) pour renouveler des jetons d’accès de courte durée dans une SPA pendant la session d’un utilisateur, sans devoir s’appuyer sur le paramètre allowRememberBrowser défini à true.

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, consultez Modifier la fréquence des requêtes d’authentification.

​

En savoir plus

• rotation des jetons d’actualisation
• Configurer rotation des jetons d’actualisation