> ## 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.

# Accès des Applications aux API : autorisations de clients

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>;
};

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Les politiques d'accès aux API pour les applications sont actuellement offertes en [accès anticipé](/docs/fr-CA/troubleshoot/product-lifecycle/product-release-stages). En utilisant cette fonctionnalité, vous acceptez les conditions applicables de version d'essai gratuite prévues dans la [Convention principale d'abonnement](https://www.okta.com/legal/?_gl=1*agihqh*_gcl_au*NjM2NjA1MDg4LjE3NTM5ODE4NjY.*_ga*MTgyNDA4MjM2Ny4xNzE1MTAyMjQy*_ga_QKMSDV5369*czE3NTQ0NzQ3NTAkbzM1MyRnMSR0MTc1NDQ3NjU5MCRqNiRsMCRoMA..) d'Okta.
</Callout>

Dans Auth0, vous pouvez contrôler la façon dont les applications accèdent à vos API à l'aide des [politiques d'accès aux API pour les applications](/docs/fr-CA/get-started/apis/api-access-policies-for-applications) et des autorisations de client.

Une autorisation de client offre un contrôle très précis de l'accès d'une application à une API. Elle associe :

* Une API identifiée par son `audience` ou son identifiant unique.
* Une application identifiée par son `client_id`.
* Une liste d'autorisations, comme des scopes et/ou des `authorization_details_types` que l'application est autorisée à demander pour l'audience spécifiée.

Pour en savoir plus sur les attributs que vous pouvez définir dans une autorisation de client, consultez [Attributs d'autorisation de client](#client-grant-attributes). Pour apprendre à définir et à gérer les autorisations de client, consultez [Configurer les autorisations de client](#configure-client-grants).

<div id="application-api-access-policies-and-client-grants">
  ## Politiques d'accès à l'API pour les applications et octrois de client
</div>

Lorsque vous configurez la [politique d'accès à l'API pour les applications](/docs/fr-CA/get-started/apis/api-access-policies-for-applications) d'une API sur `require_client_grant`, seules les applications disposant d'un octroi de client défini peuvent obtenir un jeton d’accès pour cette API. L'octroi de client définit les autorisations maximales qu’une application peut demander à l’API en appliquant le principe du moindre privilège. Par conséquent, Auth0 recommande d’utiliser `require_client_grant` lors de la configuration de la politique d’accès à l’API pour les applications.

<div id="example-social-media-api">
  ### Exemple : Social Media API
</div>

Pour illustrer comment les client grants appliquent le principe du moindre privilège, supposons que vous ayez une API Social Media avec les permissions : `read:posts`, `write:posts`, `read:friends` et `delete:posts`. Vous créez une application et définissez un client grant avec les permissions : `read:posts` et `write:posts`.

Ce client grant sert maintenant de plafond maximal. Même si l’API Social Media comporte d’autres permissions, votre application ne pourra jamais demander ou se voir accorder `read:friends` ou `delete:posts`.

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

Dans les flux d’accès utilisateur et d’accès client, les autorisations client définissent l’ensemble final des permissions qui contrôlent l’accès d’une application à une API. L’attribut `subject_type` de l’autorisation client détermine le type d’accès d’application autorisé pour une API.

Une application peut avoir jusqu’à deux autorisations client pour une même API :

* Quand vous définissez `subject_type` sur `client`, vous définissez ses permissions de type machine à machine.
* Quand vous définissez `subject_type` sur `user`, vous définissez ses permissions pour agir au nom de l’utilisateur.

Le tableau suivant explique comment les autorisations client contrôlent l’accès des applications aux API en fonction du type de flux d’accès :

<table class="table">
  <thead>
    <tr>
      <th><strong>Type d’accès</strong></th>
      <th><strong>Attribut subject\_type</strong></th>
      <th><strong>Description</strong></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>Flux Client Credentials (flux d’accès machine à machine)</td>
      <td>Définissez <code>subject\_type</code> sur <code>client</code>.</td>
      <td>L’autorisation client autorise directement l’application à accéder à l’API en son propre nom plutôt qu’au nom de l’utilisateur final. Les permissions que vous définissez dans l’autorisation client sont celles que l’application est autorisée à recevoir dans le jeton d’accès.</td>
    </tr>

    <tr>
      <td>Flux d’accès utilisateur</td>
      <td>Définissez <code>subject\_type</code> sur <code>user</code>.</td>
      <td>L’autorisation client définit les permissions maximales que l’application peut demander à l’API. Les permissions finales dans le jeton d’accès émis à l’application au nom de l’utilisateur sont l’intersection des permissions :<br /><ul><li style={{fontSize: ".875rem"}}>demandées par l’application</li><li style={{fontSize: ".875rem"}}>autorisées par l’autorisation client</li><li style={{fontSize: ".875rem"}}>autorisées par les <a href="/docs/fr-CA/manage-users/access-control/rbac">politiques de contrôle d’accès basé sur les rôles (RBAC)</a> pour l’utilisateur</li><li style={{fontSize: ".875rem"}}><a href="/docs/fr-CA/get-started/applications/confidential-and-public-applications/user-consent-and-third-party-applications">consenties par l’utilisateur final</a>, le cas échéant.</li></ul><br />Pour en savoir plus sur les flux d’accès utilisateur, consultez <a href="/docs/fr-CA/get-started/authentication-and-authorization-flow">Flux d’authentification et d’autorisation</a>. Les flux d’accès utilisateur n’incluent pas le flux Client Credentials.</td>
    </tr>
  </tbody>
</table>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Vous pouvez modifier les portées finales accordées par le serveur d’autorisation à l’application ou à l’utilisateur à l’aide des [Actions](/docs/fr-CA/customize/actions).
</Callout>

<div id="client-grant-attributes">
  ## Attributs de l’autorisation client
</div>

Une autorisation client comporte plusieurs attributs que vous pouvez définir pour configurer l’accès de l’application aux API :

<table class="table">
  <thead>
    <tr>
      <th><strong>Attribut</strong></th>
      <th><strong>Description</strong></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td><code>id</code></td>
      <td>Identifiant unique de l’autorisation client.</td>
    </tr>

    <tr>
      <td><code>audience</code></td>
      <td>Identifiant unique de l’API à laquelle s’applique l’autorisation client.</td>
    </tr>

    <tr>
      <td><code>client\_id</code></td>
      <td>L’ID unique de l’application à laquelle l’accès est accordé.</td>
    </tr>

    <tr>
      <td><code>scopes</code></td>
      <td>Un tableau de chaînes de caractères représentant les permissions que l’application peut demander.</td>
    </tr>

    <tr>
      <td><code>authorization\_details\_types</code></td>
      <td>Un tableau de chaînes de caractères représentant les types de données d’autorisation détaillées que l’application peut demander. Cet attribut peut uniquement être spécifié pour les flux d’accès utilisateur.</td>
    </tr>

    <tr>
      <td><code>subject\_type</code></td>
      <td>Le type d’accès à l’application que permet l’autorisation client :<br /><ul><li style={{fontSize: ".875rem"}}><code>user</code> : utilisé pour l’accès utilisateur, ce qui correspond à tous les flux qui génèrent un jeton associé à un utilisateur final.</li><li style={{fontSize: ".875rem"}}><code>client</code> : utilisé pour l’accès machine, ce qui correspond au flux d’informations d’identification du client (Client Credentials Flow).</li></ul></td>
    </tr>

    <tr>
      <td><code>organization\_usage</code></td>
      <td>Détermine comment l’application peut utiliser les organisations lorsqu’elle accède à l’API via le flux d’informations d’identification du client. Les valeurs possibles sont : <code>deny</code>, <code>allow</code> ou <code>require</code>.<br /><br />Pour en savoir plus sur les paramètres d’organisation, consultez <a href="/docs/fr-CA/manage-users/organizations/organizations-for-m2m-applications/configure-your-application-for-m2m-access#define-organization-behavior">Organizations for M2M Applications: Define Organization Behavior</a>.</td>
    </tr>

    <tr>
      <td><code>allow\_any\_organization</code></td>
      <td>Détermine si l’application peut accéder à n’importe quelle organisation lorsqu’elle utilise le flux d’informations d’identification du client.<br /><br />Pour en savoir plus sur les paramètres d’organisation, consultez <a href="/docs/fr-CA/manage-users/organizations/organizations-for-m2m-applications/configure-your-application-for-m2m-access#define-organization-behavior">Organizations for M2M Applications: Define Organization Behavior</a>.</td>
    </tr>
  </tbody>
</table>

<div id="configure-client-grants">
  ## Configurer les autorisations client
</div>

Vous pouvez utiliser la Management API pour configurer les autorisations client via le point de terminaison `/client-grants`.

<div id="create-client-grant">
  ### Créer une autorisation client
</div>

Pour créer une nouvelle autorisation client, effectuez une requête [`POST`](https://auth0.com/docs/api/management/v2/client-grants/post-client-grants) vers le point de terminaison `/client-grants`.

L’exemple de code suivant crée une autorisation client pour qu’une application accède à l’API `https://api.my-service.com`. Le `subject_type` est `user`, ce qui signifie que l’autorisation client est destinée à l’accès utilisateur et permet à l’application de demander la portée `read:item` et le type de détails d’autorisation `payment`.

export const codeExample1 = `curl --location 'https://{yourDomain}/api/v2/client-grants' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
--data '{
    "client_id": "{CLIENT_ID}",
    "audience": "https://api.my-service.com",
    "scope": [
        "read:item"
    ],
    "authorization_details_types":["payment"],
    "subject_type": "user"
}'`;

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

<div id="update-client-grant">
  ### Mettre à jour une autorisation client
</div>

Pour mettre à jour une autorisation client existante, effectuez une requête [`PATCH`](https://auth0.com/docs/api/management/v2/client-grants/patch-client-grants-by-id) vers `/client-grants/{id}`.

L’exemple de code suivant met à jour une autorisation client existante afin d’étendre ses autorisations. L’Application peut maintenant aussi demander la portée `update:item` et un type supplémentaire de détails d’autorisation `credits_transfer`.

export const codeExample2 = `curl --location --request PATCH 'https://{yourDomain}/api/v2/client-grants/{CLIENT_GRANT_ID}' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
--data '{
    "scope": [
        "read:item",
        "update:item"
    ],
    "authorization_details_types":["payment", "credits_transfer"]
}'`;

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

<div id="delete-client-grant">
  ### Supprimer une autorisation de client
</div>

Pour supprimer une autorisation de client, effectuez une requête [`DELETE`](https://auth0.com/docs/api/management/v2/client-grants/delete-client-grants-by-id) vers `/client-grants/{id}`.

L’exemple de code suivant supprime l’autorisation de client, ce qui révoque l’accès de l’application à l’API :

export const codeExample3 = `curl --location --request DELETE 'https://{yourDomain}/api/v2/client-grants/{CLIENT_GRANT_ID}' \
--header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}'`;

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

<div id="retrieve-client-grants">
  ### Récupérer les autorisations client
</div>

Vous pouvez aussi interroger et parcourir avec pagination les collections `client-grants` en utilisant des paramètres comme `client_id`, `audience` ou `subject_type`.

L'exemple de code suivant récupère toutes les autorisations client qui permettent l'accès des utilisateurs à l'API `https://api.my-service.com`.

export const codeExample4 = `curl --request GET \
--url 'https://{yourDomain}/api/v2/client-grants?subject_type=user&audience=https%3A%2F%2Fapi.my-service.com' \
--header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
--header 'Accept: application/json'`;

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

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

* [Politiques d’accès à l’API pour les Applications](/docs/fr-CA/get-started/apis/api-access-policies-for-applications)
* [Types d’octroi pour les Applications](/docs/fr-CA/get-started/applications/application-grant-types)