Passer au contenu principal
Le protocole OpenID Connect prend en charge le paramètre prompt=none dans la demande d’authentification, ce qui permet aux applications d’indiquer que le ne doit entraîner aucune interaction de la part de l’utilisateur (comme l’authentification, le consentement ou la ). 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 poursuivre. L’utilisation du flux implicite dans les SPA présente des enjeux de sécurité qui exigent des mesures 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 protection de la vie privée dans les navigateurs nuisent à l’expérience utilisateur en empêchant l’accès aux témoins tiers; par conséquent, les flux basés sur 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’expérience utilisateur causées par des technologies de protection de la vie privée dans les navigateurs comme ITP.

​
Initier des requêtes d’authentification silencieuse

Pour initier une requête d’authentification silencieuse, ajoutez le paramètre prompt=none lorsque vous redirigez un utilisateur vers le point de terminaison /authorize de l’API d’authentification d’Auth0. (Les paramètres de cette requête d’authentification varient en fonction des 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 spécifié (URL de rappel) au moyen du response_mode indiqué, sous l’une des deux formes suivantes : 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 :
ModeMéthode de transmissionCas d’utilisation
queryChaîne de requête (?code=...)Flux Authorization Code avec traitement côté serveur
fragmentFragment d’URL (#access_token=...)Flux implicite (ancien)
web_messageAPI postMessage()Recommandé pour les SPA — aucune navigation entre les pages requise
Lorsque vous utilisez web_message, Auth0 affiche une page HTML dans un iframe caché qui utilise l’API HTML5 Web Messaging pour renvoyer 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 plus de détails sur tous les modes de réponse, consultez OAuth 2.0 Authorization Framework.

​
Réponses d’authentification réussies

Si l’utilisateur est déjà connecté à Auth0 et qu’aucune autre interaction n’est requise, Auth0 répond exactement comme si l’utilisateur s’était authentifié manuellement à partir de la page de connexion. Le format de la réponse dépend du response_mode utilisé :
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 le SDK) écoute ce message et échange le code contre des jetons. Si l’utilisateur n’a pas de session valide, Auth0 publie 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>
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, c’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 (SSO), ou si sa session SSO avait expiré, Auth0 renvoie une erreur en utilisant le 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 envoyée au moyen de postMessage(), comme indiqué dans l’exemple ci-dessus. Les valeurs possibles de ERROR_CODE sont définies dans la spécification OpenID Connect :
RéponseDescription
login_requiredL’utilisateur n’était pas connecté à Auth0; l’authentification silencieuse n’est donc pas possible. Cette erreur peut se produire selon la façon dont les paramètres Log In Session Management du locataire sont configurés; plus précisément, elle peut survenir une fois écoulée la période définie dans le paramètre Require log in after. Consultez Configurer les paramètres de durée de vie de la session pour en savoir plus.
consent_requiredL’utilisateur était connecté à Auth0, mais il doit donner son consentement pour autoriser l’application.
interaction_requiredL’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 Rule de redirection.
Si l’une de ces erreurs est renvoyée, l’utilisateur doit être redirigé vers la page de connexion d’Auth0 sans le paramètre prompt=none afin de s’authentifier.

​
Renouveler les jetons expirés

Vous pouvez effectuer une demande 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 demande silencieuse de jeton combinée à response_mode=web_message pour les SPA, de sorte que la demande s’effectue dans un iframe masqué. Dans le cas des 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 interruption de l’expérience utilisateur (pas d’actualisation de la page ni de perte de state).
Consultez Renouveler les jetons lors de l’utilisation de Safari pour en savoir plus sur d’autres limitations importantes et solutions de contournement liées au navigateur Safari.

​
Expiration du jeton 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 en déterminer la date d’expiration. Il existe deux façons de déterminer quand 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. À la place, renouveler 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 dans le fragment d’URL à la suite d’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 anticiper son 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 lors de l’exécution de la communication web_message. Cette erreur est généralement associée au mécanisme de repli vers l’authentification inter-origine. Pour résoudre ce problème, 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 de l’.

​
Interrogation avec checkSession()

Dans certains scénarios impliquant plusieurs applications, lorsqu’une déconnexion unique est souhaitée (si un utilisateur se déconnecte d’une application, il doit aussi être déconnecté des autres), 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 aussi être utilisée pour mettre en œuvre l’authentification silencieuse dans un scénario d’authentification unique (SSO). L’intervalle entre les appels à checkSession() doit être d’au moins 15 minutes afin d’éviter tout problème futur lié à la limitation du débit pour cet appel.

​
Authentification silencieuse avec l’authentification multifacteur

Dans certains cas, vous pourriez vouloir éviter de demander à l’utilisateur de passer par l’authentification multifacteur (MFA) chaque fois qu’il ouvre une session dans le même navigateur. Pour ce faire, configurez une Rule afin que la MFA n’ait lieu qu’une seule fois par session. Cela est utile lorsque vous effectuez une authentification silencieuse (prompt=none) pour renouveler des jetons d’accès de courte durée dans une SPA pendant la session de l’utilisateur, sans avoir à définir allowRememberBrowser sur 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 demandes d’authentification.

​
En savoir plus