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

# Politiques d'accès aux API pour les Applications

export const AuthCodeBlock = ({filename, icon, language, highlight, children}) => {
  const [processedChildren, setProcessedChildren] = useState(children);
  useEffect(() => {
    let unsubscribe = null;
    function init() {
      unsubscribe = window.autorun(() => {
        let processedChildren = children;
        for (const [key, value] of window.rootStore.variableStore.values.entries()) {
          processedChildren = processedChildren.replace(new RegExp(key, "g"), value);
        }
        setProcessedChildren(processedChildren);
      });
    }
    if (window.rootStore) {
      init();
    } else {
      window.addEventListener("adu:storeReady", init);
    }
    return () => {
      window.removeEventListener("adu:storeReady", init);
      unsubscribe?.();
    };
  }, [children]);
  return <CodeBlock filename={filename} icon={icon} language={language} lines highlight={highlight}>
      {processedChildren}
    </CodeBlock>;
};

<Warning>
  API Access Policies for Applications est actuellement offerte en [accès anticipé](/docs/fr-CA/troubleshoot/product-lifecycle/product-release-stages). En utilisant cette fonctionnalité, vous acceptez les modalités d’essai gratuit applicables du [Master Subscription Agreement](https://www.okta.com/legal/?_gl=1*agihqh*_gcl_au*NjM2NjA1MDg4LjE3NTM5ODE4NjY.*_ga*MTgyNDA4MjM2Ny4xNzE1MTAyMjQy*_ga_QKMSDV5369*czE3NTQ0NzQ3NTAkbzM1MyRnMSR0MTc1NDQ3NjU5MCRqNiRsMCRoMA..) d’Okta.
</Warning>

API Access Policies for Applications vous permet de contrôler la façon dont les applications accèdent à vos API enregistrées dans Auth0. Ces stratégies définissent comment les applications interagissent avec une API, par exemple si elles peuvent obtenir un jeton d’accès pour accéder aux ressources de l’API.

Vous pouvez configurer la stratégie d’accès à l’API pour les applications pour chaque API enregistrée dans l’Auth0 Dashboard. Pour en savoir plus, consultez [Configurer la stratégie d’accès à l’API pour les applications](#configure-api-application-access-policy).

<div id="user-access-vs-client-access-flows">
  ## Flux d’accès utilisateur vs flux d’accès client
</div>

Vous pouvez configurer des politiques distinctes d’accès à l’API d’application pour les flux d’accès utilisateur et les flux d’accès client (machine à machine) :

* **Accès client** : utilisé pour l’accès machine à machine, qui correspond au [Client Credentials Flow](/docs/fr-CA/get-started/authentication-and-authorization-flow/client-credentials-flow).
* **Accès utilisateur** : utilisé pour tous les flux d’accès qui génèrent un jeton d’accès associé à un utilisateur final, ce qui permet à l’application d’accéder à une API au nom de l’utilisateur. Les flux d’accès utilisateur n’incluent pas le Client Credentials Flow. Pour en savoir plus sur les flux d’accès utilisateur, consultez [Authentication and Authorization Flows](/docs/fr-CA/get-started/authentication-and-authorization-flow).

<div id="application-api-access-policies">
  ## Stratégies d'accès des applications aux API
</div>

Les stratégies d'accès des applications aux API sont :

<table class="table">
  <thead>
    <tr>
      <th><strong>Stratégie</strong></th>
      <th><strong>Description</strong></th>
      <th><strong>Flux d'accès</strong></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td><code>allow\_all</code></td>
      <td>Lorsqu’elle est configurée pour une API, toute application de votre tenant peut obtenir un jeton d’accès pour l’API. Aucun grant spécifique n’est requis.</td>
      <td>Valeur par défaut pour les flux d’accès utilisateur lorsque vous créez une API. Vous pouvez uniquement configurer <code>allow\_all</code> pour les flux d’accès utilisateur.</td>
    </tr>

    <tr>
      <td><code>require\_client\_grant</code></td>
      <td>Lorsqu’elle est configurée pour une API, seules les applications avec un client grant défini peuvent obtenir un jeton d’accès pour l’API. Le client grant établit les permissions maximales qu’une application peut demander à l’API. Pour en savoir plus sur la création et la gestion des client grants, consultez <a href="/docs/fr-CA/get-started/applications/application-access-to-apis-client-grants">Application Access to APIs: Client Grants</a>.</td>
      <td>Valeur par défaut pour le flux Client Credentials Flow lorsque vous créez une API.</td>
    </tr>

    <tr>
      <td><code>deny\_all</code></td>
      <td>Lorsqu’elle est configurée pour une API, aucune application ne peut obtenir un jeton d’accès pour l’API, quelles que soient les autres configurations ou grants. L’accès est complètement restreint.</td>
      <td>Vous pouvez configurer <code>deny\_all</code> pour les flux d’accès utilisateur et client.</td>
    </tr>
  </tbody>
</table>

Lorsque vous configurez la stratégie d’accès des applications à une API, Auth0 recommande d’utiliser `require_client_grant`, qui suit une approche basée sur le principe du moindre privilège. Pour en savoir plus, consultez [Application Access to APIs: Client Grants](/docs/fr-CA/get-started/applications/application-access-to-apis-client-grants).

Lorsque vous définissez la stratégie d’accès des applications d’une API sur `require_client_grant`, vous devez fournir explicitement les scopes requis dans la requête de jeton. Cela ne s’applique pas aux requêtes de jeton d’actualisation où, si vous omettez les scopes, le Serveur d’autorisation suppose que l’application souhaite obtenir tous les scopes qui lui ont été accordés dans le jeton d’accès d’origine. En conséquence, le Serveur d’autorisation renvoie un jeton d’accès avec les mêmes scopes que ceux accordés initialement par le propriétaire de la ressource.

<div id="configure-api-application-access-policy">
  ## Configurer la stratégie d’accès des applications à l’API
</div>

Vous pouvez configurer la stratégie d’accès des applications à une API en mettant à jour sa propriété `subject_type_authorization` dans la collection `resource-servers`.

L’objet `subject_type_authorization` contient deux objets imbriqués, `user` et `client`, chacun avec un attribut de stratégie que vous pouvez définir sur l’une des trois stratégies d’accès décrites dans [Stratégies d’accès des applications à l’API](#application-api-access-policies).

<div id="existing-api">
  ### API existante
</div>

Pour configurer la stratégie d’accès des applications pour une API existante, effectuez une requête `PATCH` vers le point de terminaison `/resource-servers/{id}` et transmettez un objet `subject_type_authorization` qui spécifie les stratégies pour les types d’accès utilisateur et client.

L’exemple de code suivant montre comment définir différentes stratégies d’accès pour les types d’accès utilisateur et client pour une API existante :

* La stratégie utilisateur est définie sur `require_client_grant`, ce qui signifie que les applications doivent disposer d’un client grant pour accéder à l’API au nom de l’utilisateur.
* La stratégie client est définie sur `deny_all`, ce qui restreint l’accès machine-à-machine à cette API.

export const codeExample1 = `curl --location --request PATCH 'https://{yourDomain}/api/v2/resource-servers/{RESOURCE_SERVER_ID}' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
--data '{
    "subject_type_authorization": {
        "user": {
            "policy": "require_client_grant"
        },
        "client": {
            "policy": "deny_all"
        }
    }
}'`;

<AuthCodeBlock children={codeExample1} language="bash" />

<div id="new-api">
  ### Nouvelle API
</div>

Pour configurer la stratégie d’accès à l’application lors de la création d’une nouvelle API, effectuez une requête `POST` vers le point de terminaison `/resource-servers` et transmettez un objet `subject_type_authorization` qui spécifie les stratégies pour les types d’accès utilisateur et client.

L’exemple de code suivant montre comment définir différentes stratégies d’accès pour les types d’accès utilisateur et client lors de la création d’une nouvelle API :

* La stratégie utilisateur est définie sur `require_client_grant`, ce qui signifie que les applications doivent avoir une autorisation client pour accéder à l’API au nom de l’utilisateur.
* La stratégie client est définie sur `deny_all`, ce qui restreint l’accès machine-à-machine à cette API.

export const codeExample2 = `curl --location 'https://{yourDomain}/api/v2/resource-servers' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
--data '{
  "name": "{YOUR_NEW_API_NAME}",
  "identifier": "{YOUR_NEW_API_IDENTIFIER}",
  "scopes": [
    {
      "value": "{SCOPE_VALUE}",
      "description": "{SCOPE_DESCRIPTION}"
    }
  ],
  "subject_type_authorization": {
    "user": {
      "policy": "require_client_grant"
    },
    "client": {
      "policy": "deny_all"
    }
  }
}'`;

<AuthCodeBlock children={codeExample2} language="bash" />

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

* [Accès des Applications aux API : autorisations de client (Client Grants)](/docs/fr-CA/get-started/applications/application-access-to-apis-client-grants)