> ## 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 sécuriser un outil de ligne de commande avec Auth0 à l’aide des flux d’autorisation d’appareil et d’octroi des informations d’identification client.

# Sécuriser une CLI avec Auth0

Les trois façons de sécuriser une CLI avec Auth0, de la plus sûre à la moins sûre, sont :

* [flux d’autorisation d’appareil](#device-authorization-flow) lorsque l'utilisateur ne peut pas ouvrir de navigateur
* [Client Credentials Grant Flow](#client-credentials-grant-flow) pour les applications qui agissent en leur propre nom et ne sont pas attribuables à un utilisateur
* [Resource Owner Password Grant Flow](#resource-owner-password-grant-flow) uniquement lorsque vous tentez d'authentifier le client CLI lui-même, ce qui est très rare (autrement, ce n'est pas recommandé)

<div id="device-authorization-flow">
  ## Flux d’autorisation d’appareil
</div>

Avec les appareils à saisie limitée qui se connectent à Internet, au lieu d’authentifier directement l’utilisateur, l’appareil lui demande d’aller à un lien sur son ordinateur ou son téléphone intelligent et d’autoriser l’appareil. Cela évite une mauvaise expérience utilisateur sur les appareils qui n’offrent pas de moyen simple de saisir du texte. Pour ce faire, les applications de l’appareil utilisent le Device <Tooltip tip="Flux d’autorisation : grant d’autorisation (ou workflow) défini dans le framework OAuth 2.0." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Authorization+Flow">Flux d’autorisation</Tooltip> (défini dans une version préliminaire d’OAuth 2.0), dans lequel elles transmettent leur <Tooltip tip="Client ID : valeur d’identification attribuée à votre ressource enregistrée par Auth0." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Client+ID">Client ID</Tooltip> pour lancer le processus d’autorisation et obtenir un token.

La façon la plus simple de mettre en place le Flux d’autorisation d’appareil est de suivre les étapes de [Appeler l’API à l’aide du Flux d’autorisation d’appareil](/docs/fr-ca/get-started/authentication-and-authorization-flow/device-authorization-flow/call-your-api-using-the-device-authorization-flow).

Pour en savoir plus sur le Flux d’autorisation d’appareil dans <Tooltip tip="OAuth 2.0 : framework d’autorisation qui définit les protocoles et workflows d’autorisation." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip>, vous pouvez consulter la version préliminaire de l’Internet Engineering Task Force (IETF), [OAuth 2.0 Authorization Grant](https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15). Vous pouvez aussi consulter notre article [Flux d’autorisation d’appareil](/docs/fr-ca/get-started/authentication-and-authorization-flow/device-authorization-flow).

<div id="client-credentials-grant-flow">
  ## Client Credentials Grant Flow
</div>

Utilisez le flux Client Credentials Grant (CCG) lorsque les utilisateurs et les <Tooltip tip="Identity Provider (IdP) : Service qui stocke et gère les identités numériques." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=identity+providers">fournisseurs d’identité</Tooltip> sous-jacents ne sont pas en cause et que vous souhaitez vous authentifier à l’aide de machines ou d’appareils distincts.

Si votre fournisseur d’identité prend en charge l’envoi de données d’identification, nous vous recommandons de consulter notre article [Client Credentials Flow](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-credentials-flow). Pour savoir comment mettre en œuvre ce flux, consultez [Call API Using the Client Credentials Flow](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-credentials-flow/call-your-api-using-the-client-credentials-flow).

<div id="resource-owner-password-grant-flow">
  ## Resource Owner Password Grant Flow
</div>

Nous ne recommandons pas d’utiliser le flux <Tooltip tip="Resource Owner : entité (comme un utilisateur ou une application) capable d’accorder l’accès à une ressource protégée." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Resource+Owner">Resource Owner</Tooltip> Password Grant (ROPG) pour les applications natives. Dans l’article de l’IETF, [RFC 8252 OAuth 2.0 for Native Apps](https://tools.ietf.org/html/rfc8252), il est recommandé que « les demandes d’autorisation OAuth 2.0 provenant d’applications natives soient effectuées UNIQUEMENT au moyen d’agents utilisateurs externes, principalement le navigateur de l’utilisateur ». Pour en savoir plus, consultez [RFC 8252 Embedded User-Agents](https://tools.ietf.org/html/rfc8252#section-8.12).

L’utilisation du Resource Owner Password Grant (ROPG) est moins sécuritaire que les options basées sur la redirection décrites ci-dessus. ROPG est réservé aux scénarios Legacy. Dans le contexte des CLI, cela n’a vraiment de sens que pour des éléments comme les chaînes de connexion, lorsque vous devez prendre en charge des programmes existants.

Si vous devez absolument utiliser ROPG dans votre application native au lieu de Device Flow, comme nous le recommandons, vous pouvez alors utiliser notre [point de terminaison ROPG conforme à OIDC](https://auth0.com/docs/api/authentication#resource-owner-password).