Sécuriser une interface de ligne de commande avec Auth0

Il y a trois façons de sécuriser une interface de ligne de commande avec Auth0, selon un niveau de sécurité décroissant :

• Flux d’autorisation d’appareil lorsqu’un utilisateur n’arrive pas à ouvrir un navigateur

• Flux d’autorisation des identifiants client pour les applications agissant seules, non attribuables à un utilisateur

• Le mot de passe du propriétaire de la ressource ne sera accordé que lorsque vous tenterez d’authentifier le client de l’interface de ligne de commande, une occurrence plutôt rare. Dans tous les autres cas, il est déconseillé de procéder ainsi.

Au lieu d’authentifier directement les utilisateurs, les appareils à saisie limitée qui se connectent à l’internet demandent aux utilisateurs d’aller cliquer sur un lien sur leur ordinateur ou leur téléphone intelligent et d’y autoriser l’appareil. Cela permet d'améliorer l'expérience utilisateur pour les appareils qui ne disposent pas d'un moyen facile de saisir du texte. Pour ce faire, les applications des appareils utilisent le flux d’autorisation d’appareil (rédigé dans OAuth 2.0), dans lequel elles transmettent leur ID client pour lancer le processus d’autorisation et obtenir un jeton.

La manière la plus simple d’implémenter le Flux d’autorisation d’appareil consiste à suivre les étapes décrites dans Appeler l’API avec le flux d’autorisation d’appareil.

Pour en savoir plus sur le flux d’autorisation d’appareil dans OAuth 2.0, vous pouvez lire le document OAuth 2.0 Authorization Grant de l’Internet Engineering Task Force (IEFT). Vous pouvez aussi lire notre article Flux d’autorisation d’appareil.

Use the Client Credentials Grant (CCG) flow when users and downstream identity providers aren’t involved, and you want to authenticate based on distinct machines or devices.

Si votre fournisseur d’identité prend en charge l’envoi d’identifiants, lisez notre article Flux des identifiants client. Pour en savoir plus sur l’implémentation de ce flux, reportez-vous à Appeler l’API à l’aide du flux des identifiants client.

Nous ne recommandons pas d’utiliser le flux d’autorisation par mot de passe du propriétaire de la ressource (ROPG) avec les applications natives. Comme expliqué dans l’article de l’IEFT RFC 8252 OAuth 2.0 for Native Apps , « Les demandes d’autorisation OAuth 2.0 des applications natives ne devraient être effectuées QUE par l’intermédiaire d’agents utilisateurs externes, principalement le navigateur de l’utilisateur ». Pour en savoir plus, voir Agents d’utilisateurs intégrés RFC 8252. 

L’utilisation de l’autorisation par mot de passe du propriétaire de la ressource (ROPG) est moins sûre que les options basées sur la redirection décrites ci-dessus. ROPG ne concerne que des cas obsolètes. Dans le contexte des interfaces de ligne de commande, elle n’a de sens que pour des chaînes de connexion où vous devez prendre en charge des programmes obsolètes.

Si vous devez utiliser ROPG dans votre application native au lieu du flux de l’appareil comme nous le recommandons, vous pouvez alors utiliser notre point de terminaison ROPG conforme à l’OIDC.