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

> Comment utiliser Auth0 pour sécuriser une CLI.

# Sécuriser une CLI avec Auth0

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

* [Flux d’autorisation d’appareil](#device-authorization-flow) lorsque l’utilisateur ne peut pas ouvrir de navigateur
* [Flux d’octroi des informations d’identification du client](#client-credentials-grant-flow) pour les applications qui agissent en leur propre nom et ne peuvent pas être attribuées à un utilisateur
* [Flux d’octroi par mot de passe du propriétaire de la ressource](#resource-owner-password-grant-flow) uniquement lorsque vous essayez d’authentifier le client CLI lui-même, ce qui est très rare (sinon, ce n’est pas recommandé)

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

Avec les appareils dont les capacités de saisie sont limitées et qui se connectent à Internet, au lieu d’authentifier directement l’utilisateur, l’appareil lui demande d’ouvrir un lien sur son ordinateur ou son smartphone et d’autoriser l’appareil. Cela évite une expérience utilisateur médiocre sur les appareils qui n’offrent pas de moyen simple de saisir du texte. Pour ce faire, les applications pour appareils utilisent le <Tooltip tip="Flux d’autorisation : octroi d’autorisation (ou flux de travail) spécifié dans le cadre OAuth 2.0." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Authorization+Flow">flux d’autorisation</Tooltip> d’appareil (décrit dans OAuth 2.0), dans lequel elles transmettent leur <Tooltip tip="ID client : valeur d’identification attribuée à votre ressource enregistrée par Auth0." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Client+ID">ID client</Tooltip> pour lancer le processus d’autorisation et obtenir un jeton.

La façon la plus simple d’implémenter le flux d’autorisation d’appareil consiste à suivre les étapes de [Appeler une API à l’aide du flux d’autorisation d’appareil](/fr-CA/docs/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 : cadre d’autorisation qui définit les protocoles et les flux de travail d’autorisation." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip>, vous pouvez consulter le brouillon de l’Internet Engineering Task Force (IEFT) [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](/fr-CA/docs/get-started/authentication-and-authorization-flow/device-authorization-flow).

<div id="client-credentials-grant-flow">
  ## Flux d’octroi des informations d’identification du client
</div>

Utilisez le flux d’octroi des informations d’identification du client (CCG) lorsque les utilisateurs et les <Tooltip tip="fournisseur d’identité (IdP) : service qui stocke et gère les identités numériques." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=identity+providers">fournisseurs d’identité</Tooltip> en aval ne sont pas en cause et que vous souhaitez authentifier des machines ou des appareils distincts.

Si votre fournisseur d’identité prend en charge l’envoi d’informations d’identification, consultez notre article [Flux Client Credentials](/fr-CA/docs/get-started/authentication-and-authorization-flow/client-credentials-flow). Pour savoir comment mettre en œuvre ce flux, consultez [Appeler une API à l’aide du flux Client Credentials](/fr-CA/docs/get-started/authentication-and-authorization-flow/client-credentials-flow/call-your-api-using-the-client-credentials-flow).

<div id="resource-owner-password-grant-flow">
  ## Flux d’octroi par mot de passe du propriétaire de la ressource
</div>

Nous ne recommandons pas d’utiliser le flux <Tooltip tip="Propriétaire de la ressource : entité (comme un utilisateur ou une application) capable d’accorder l’accès à une ressource protégée." cta="Voir le glossaire" href="/fr-CA/docs/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 ne soient effectuées QUE par l’intermédiaire 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).

Le flux Resource Owner Password Grant (ROPG) est moins sûr que les options basées sur la redirection décrites ci-dessus. ROPG est réservé aux systèmes hérités. Dans le contexte des CLI, cela n’a de sens que pour des cas comme les chaînes de connexion, lorsque vous devez prendre en charge des programmes hérités.

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