Passer au contenu principal
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

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 d’appareil (décrit dans OAuth 2.0), dans lequel elles transmettent leur 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. Pour en savoir plus sur le flux d’autorisation d’appareil dans , vous pouvez consulter le brouillon de l’Internet Engineering Task Force (IEFT) OAuth 2.0 Authorization Grant. Vous pouvez aussi consulter notre article, Flux d’autorisation d’appareil.

​
Flux d’octroi des informations d’identification du client

Utilisez le flux d’octroi des informations d’identification du client (CCG) lorsque les utilisateurs et les 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. Pour savoir comment mettre en œuvre ce flux, consultez Appeler une API à l’aide du flux Client Credentials.

​
Flux d’octroi par mot de passe du propriétaire de la ressource

Nous ne recommandons pas d’utiliser le flux Password Grant (ROPG) pour les applications natives. Dans l’article de l’IETF, RFC 8252 OAuth 2.0 for Native Apps, 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. 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.