Sécuriser une CLI avec Auth0

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.

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 lorsque l’utilisateur ne peut pas ouvrir de navigateur
• 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 uniquement lorsque vous tentez d’authentifier le client CLI lui-même, ce qui est très rare (autrement, ce n’est pas recommandé)

​

Flux d’autorisation d’appareil

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 Flux d’autorisation (défini dans une version préliminaire d’OAuth 2.0), dans lequel elles transmettent leur Client ID 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.

Pour en savoir plus sur le Flux d’autorisation d’appareil dans OAuth 2.0, vous pouvez consulter la version préliminaire de l’Internet Engineering Task Force (IETF), OAuth 2.0 Authorization Grant. Vous pouvez aussi consulter notre article Flux d’autorisation d’appareil.

​

Client Credentials Grant Flow

Utilisez le flux Client Credentials Grant (CCG) lorsque les utilisateurs et les fournisseurs d’identité 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. Pour savoir comment mettre en œuvre ce flux, consultez Call API Using the Client Credentials Flow.

​

Resource Owner Password Grant Flow

Nous ne recommandons pas d’utiliser le flux Resource Owner 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 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.

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.