Parlons de sécurité avec les API, c’est-à-dire comment identifier de manière sûre « le caller » dans Azure. En effet, en travaillant avec des développeurs ce sujet devient de plus en plus sérieux.
Il existe deux méthodes d’authentification assez populaires dans le cloud (en général) pour sécuriser les API :
- Key-based access
- OAuth, or token-based access
Faisons une comparaison :
Key-Based :
Par Key-based, j’entends un système d’authentification dans lequel je peux transmettre une clé à la requête API. Cette clé peut se trouver dans la chaîne de requête ou dans l’en-tête HTTP. Voici un exemple d’authentification par clé dans Azure (liste non exhaustive des différents services Azure qui utilisent Key-based) :
- Blob REST API
- Azure Function
- Logic Apps
- Service Bus (via SAS token)
OAuth / Token-based access :
En général, un mécanisme basé sur des tokens, est un dispositif d’authentification dans lequel les informations d’identification et les secrets sont transmis à un fournisseur de tokens qui renvoie un jeton et le transmet ensuite à la partie qui s’y fie ou aux API :
Exemple d’authentification OAuth dans Azure (liste non exhaustive) :
- Azure Active Directory (en tant que IDS)
- Data Lake Storage (ADLS) REST API
- Azure Management REST API
Pros & Cons :
Au lieu de donner un tableau des avantages et des inconvénients bien formaté où tous les avantages ont un inconvénient correspondant, discutons simplement des principaux aspects : la sécurité et la complexité.
En général, l’OAuth est plus sécurisé, mais plus complexe pour les clients et les services. Pourquoi l’OAuth est-il plus sécurisé ?
Les parties utilisatrices ne voient jamais les informations d’identification et les secrets dans un schéma d’authentification OAuth. Elles voient des tokens. Ces derniers sont révoqués au bout d’un certain temps, souvent quelques minutes, au maximum quelques heures.
D’un autre côté, les clés sont transmises directement aux parties qui s’y fient. Si elles sont communiquées sous forme de chaînes de requête, elles seront effectivement vérifiées. Il est donc beaucoup plus facile de dérober des clés. Chaque API que nous mettons en œuvre doit manier les clés et nous devons nous assurer que nous les gérons correctement.
De plus, les clés ne sont généralement pas nombreuses. Par exemple, Azure Blob Storage possède une clé primaire et une clé secondaire que nous ne pouvons que révoquer. Si plus de deux utilisateurs manipulent le même compte, ils doivent partager la même clé. Il est de plus en plus difficile de vérifier quel consommateur utilise le service.
L’Oauth se fie à une partie qui traite les secrets, c’est-à-dire les providers (fournisseurs) d’identité. Par exemple, l’Azure AD est un provider d’identité et les équipes de Microsoft ont fait beaucoup d’efforts afin de durcir la gestion des secrets. De plus, les providers d’identité permettent généralement la présence de plusieurs utilisateurs, service users et service principals, ce qui facilite la vérification et l’audit des clients (qui utilisent les clés).
D’un autre côté, nous avons mentionné la complexité. Il est assez facile de voir qu’OAuth est plus compliqué. Au lieu d’invoquer directement une API, nous devons d’abord obtenir un jeton, puis le passer. Du côté des services, nous devons prendre ce jeton puis le valider. Cela nécessite souvent une opération cryptographique difficile.
Cette complexité peut désormais être atténuée par la plateforme. Par exemple, Azure App Service peut se charger entièrement de la tâche de validation.
Conclusion :
L’authentification est un aspect essentiel de la conception d’une API. L’OAuth devrait être favorisé pour ses avantages en matière de sécurité, mais les clés ont un point d’entrée beaucoup plus bas.
Il est bien sûr possible de soutenir les deux, en permettant aux consommateurs de commencer avec des clés pour “chauffer les pneus” et de passer à l’OAuth pour un travail plus sérieux.
