> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

# Configurer l’authentification silencieuse

export const AuthCodeBlock = ({filename, icon, language, highlight, children}) => {
  const [displayText, setDisplayText] = useState(children);
  const [copyText, setCopyText] = useState(children);
  const wrapperRef = React.useRef(null);
  useEffect(() => {
    let unsubscribe = null;
    function init() {
      if (!window.autorun || !window.rootStore) {
        return;
      }
      unsubscribe = window.autorun(() => {
        let processedChildrenForDisplay = children;
        let processedChildrenForCopy = children;
        for (const [key, value] of window.rootStore.variableStore.values.entries()) {
          const escapedKey = key.replaceAll(/[.*+?^${}()|[\]\\]/g, (String.raw)`\$&`);
          let displayValue = value;
          if (key === "{yourClientSecret}" && value !== "{yourClientSecret}") {
            displayValue = value.substring(0, 3) + "*****MASKED*****";
          }
          processedChildrenForDisplay = processedChildrenForDisplay.replaceAll(new RegExp(escapedKey, "g"), displayValue);
          processedChildrenForCopy = processedChildrenForCopy.replaceAll(new RegExp(escapedKey, "g"), value);
        }
        setDisplayText(processedChildrenForDisplay);
        setCopyText(processedChildrenForCopy);
      });
    }
    if (window.rootStore) {
      init();
    } else {
      window.addEventListener("adu:storeReady", init);
    }
    return () => {
      window.removeEventListener("adu:storeReady", init);
      unsubscribe?.();
    };
  }, [children]);
  useEffect(() => {
    if (!wrapperRef.current) return;
    const originalWriteText = navigator.clipboard.writeText.bind(navigator.clipboard);
    let isOverriding = false;
    const handleClick = e => {
      const button = e.target.closest('[data-testid="copy-code-button"]');
      if (!button || !wrapperRef.current.contains(button)) return;
      isOverriding = true;
      navigator.clipboard.writeText = text => {
        if (isOverriding) {
          isOverriding = false;
          navigator.clipboard.writeText = originalWriteText;
          return originalWriteText(copyText);
        }
        return originalWriteText(text);
      };
      setTimeout(() => {
        if (isOverriding) {
          isOverriding = false;
          navigator.clipboard.writeText = originalWriteText;
        }
      }, 100);
    };
    const wrapper = wrapperRef.current;
    wrapper.addEventListener('click', handleClick, true);
    return () => {
      wrapper.removeEventListener('click', handleClick, true);
      if (navigator.clipboard.writeText !== originalWriteText) {
        navigator.clipboard.writeText = originalWriteText;
      }
    };
  }, [copyText]);
  return <div ref={wrapperRef}>
      <CodeBlock filename={filename} icon={icon} language={language} lines highlight={highlight}>
        {displayText}
      </CodeBlock>
    </div>;
};

Le [protocole OpenID Connect](/fr-CA/docs/authenticate/protocols/openid-connect-protocol) prend en charge le paramètre `prompt=none` dans la demande d’authentification, ce qui permet aux applications d’indiquer que le <Tooltip tip="Serveur d’autorisation : serveur centralisé qui contribue à définir les limites de l’accès d’un utilisateur. Par exemple, votre serveur d’autorisation peut contrôler les données, les tâches et les fonctionnalités accessibles à un utilisateur." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=authorization+server">serveur d’autorisation</Tooltip> ne doit entraîner aucune interaction de la part de l’utilisateur (comme l’authentification, le consentement ou la <Tooltip tip="Serveur d’autorisation : serveur centralisé qui contribue à définir les limites de l’accès d’un utilisateur. Par exemple, votre serveur d’autorisation peut contrôler les données, les tâches et les fonctionnalités accessibles à un utilisateur." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=MFA">MFA</Tooltip>). 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](/fr-CA/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post) 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](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) conjointement avec l’authentification silencieuse pour renouveler les sessions dans les SPA.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](/fr-CA/docs/secure/tokens/refresh-tokens/refresh-token-rotation), 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.
</Callout>

<div id="initiate-silent-authentication-requests">
  ## Initier des requêtes d’authentification silencieuse
</div>

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](https://auth0.com/docs/api/authentication#authorize-application). (Les paramètres de cette requête d’authentification varient en fonction des besoins précis de votre application.)

Par exemple :

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

<AuthCodeBlock children={codeExample} language="json" />

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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Toutes les [Rules](/fr-CA/docs/customize/rules) applicables seront exécutées dans le cadre du processus d’authentification silencieuse.
</Callout>

<div id="response-modes">
  ### Modes de réponse
</div>

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          | Méthode de transmission              | Cas d’utilisation                                                       |
| ------------- | ------------------------------------ | ----------------------------------------------------------------------- |
| `query`       | Chaîne de requête (`?code=...`)      | Flux Authorization Code avec traitement côté serveur                    |
| `fragment`    | Fragment d’URL (`#access_token=...`) | Flux implicite (ancien)                                                 |
| `web_message` | API `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](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) pour renvoyer le résultat à votre application. Cela permet l’authentification silencieuse sans redirection visible ni perte d’état.

<Note>
  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](https://manage.auth0.com/#/applications). Pour plus de détails sur tous les modes de réponse, consultez [OAuth 2.0 Authorization Framework](/fr-CA/docs/authenticate/protocols/oauth#authorization-endpoint).
</Note>

<div id="successful-authentication-responses">
  ### Réponses d’authentification réussies
</div>

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é :

<Tabs>
  <Tab title="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 :

    ```html theme={null}
    <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 :

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

  <Tab title="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 :

    ```text theme={null}
    GET https://yourApp.com/callback
        #id_token=eyJhbG...&
        access_token=eyJhbG...&
        state=your_state_value&
        expires_in=86400
    ```
  </Tab>

  <Tab title="query">
    Lorsque vous utilisez `response_mode=query` (par défaut pour le flux Authorization Code avec `response_type=code`), Auth0 redirige avec le code dans la chaîne de requête :

    ```text theme={null}
    GET https://yourApp.com/callback
        ?code=SplX...GT&
        state=your_state_value
    ```
  </Tab>
</Tabs>

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.

<div id="error-responses">
  ### Réponses d’erreur
</div>

Si l’utilisateur n’était pas connecté au moyen de <Tooltip tip="Authentification unique (SSO) : service qui, après la connexion d’un utilisateur à une application, le connecte automatiquement à d’autres applications." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Single+Sign-on">authentification unique</Tooltip> (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`) :

```text theme={null}
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](https://openid.net/specs/openid-connect-core-1_0.html#AuthError) :

| 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 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](/fr-CA/docs/manage-users/sessions/configure-session-lifetime-settings) 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 [Rule de redirection](/fr-CA/docs/customize/rules/redirect-users).                                                                                                                                                                                                                                                  |

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.

<div id="renew-expired-tokens">
  ## Renouveler les jetons expirés
</div>

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](/fr-CA/docs/libraries/auth0js) 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`).

<div id="access-token-expiration">
  ### Expiration du jeton d’accès
</div>

<Tooltip tip="Jeton d’accès : justificatif d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisé pour accéder à une API." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Access+Tokens">Jetons d’accès</Tooltip> 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](/fr-CA/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post), 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](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-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.

<div id="error-response">
  ### Réponse d’erreur
</div>

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’<Tooltip tip="Auth0 Dashboard : produit principal d’Auth0 pour configurer vos services." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Auth0+Dashboard">Auth0 Dashboard</Tooltip>.

<div id="poll-with-checksession">
  ## Interrogation avec checkSession()
</div>

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.

<div id="silent-authentication-with-multi-factor-authentication">
  ## Authentification silencieuse avec l’authentification multifacteur
</div>

Dans certains cas, vous pourriez vouloir éviter de demander à l’utilisateur de passer par l’[authentification multifacteur (MFA)](/fr-CA/docs/secure/multi-factor-authentication) 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`.

```js lines theme={null}
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](/fr-CA/docs/secure/multi-factor-authentication/customize-mfa).

<div id="learn-more">
  ## En savoir plus
</div>

* [Rotation des jetons d’actualisation](/fr-CA/docs/secure/tokens/refresh-tokens/refresh-token-rotation)
* [Configurer la rotation des jetons d’actualisation](/fr-CA/docs/secure/tokens/refresh-tokens/configure-refresh-token-rotation)