REST-API: Basic Authentication vs. OAuth 2.0

Lors de l'utilisation de la REST API, différents mécanismes d'authentification peuvent être utilisés en fonction du scénario et des exigences de sécurité. 

Pour un aperçu complet de tous les mécanismes, veuillez consulter notre Guide du Développeur : API Guide | BOC Developer Portal

Deux méthodes couramment citées sont l'Basic Authentication et OAuth 2.0, car elles offrent des approches relativement simples.

Bien que les deux méthodes permettent l'accès à l'API, elles diffèrent significativement en termes de modèle de sécurité, d'effort de configuration et de cas d'utilisation prévus. Le choix de la méthode appropriée n'est donc pas seulement une décision technique, mais dépend également des politiques de sécurité de votre organisation et du type d'intégration que vous mettez en œuvre.
 

Important : 
La configuration décrite dans cet article doit être validée en fonction de vos politiques internes de sécurité, et ne fournit que des recommandations et des informations de bonnes pratiques. 

Les configurations en production doivent toujours être mises en œuvre et révisées par des administrateurs IT expérimentés.

Basic Authentication

L'Basic Authentication est la plus simple des deux approches. Elle repose sur l'envoi d'un nom d'utilisateur et d'un mot de passe avec chaque requête API. Cela la rend facile à configurer et adaptée pour des tests rapides ou des intégrations simples.

Cependant, cette simplicité comporte des limites. Puisque les informations d'identification sont transmises à chaque requête, il n'y a pas de séparation entre authentification et autorisation au-delà des permissions attribuées à l'utilisateur. De plus, il n'existe pas de notion de durée de vie du jeton ou d'accès limité, ce qui réduit le niveau de sécurité global comparé à OAuth.

Pour cette raison, l'Basic Authentication est généralement recommandée uniquement pour des scénarios non productifs ou des tests à court terme.
 

Documentation : Activation de l'Basic Authentication - BOC Docs

Exigences pour l'Basic Authentication

Lors de l'utilisation de l'Basic Authentication, les conditions utilisateur suivantes doivent être remplies :

• L'utilisateur doit être un utilisateur défini localement dans le système. 
• Les utilisateurs importés ou authentifiés via Single Sign-On (SSO) ne peuvent pas être utilisés dans ce contexte. 
• L'utilisateur ne doit pas être configuré en tant qu'utilisateur technique.
• Accès au Référentiel configuré.

Lors de l'utilisation de l'Basic Authentication, les conditions système suivantes doivent être remplies :

L'accès doit être restreint au niveau réseau en autorisant uniquement certaines adresses IP clientes : Authentification. 

Veuillez noter : Après la configuration, un redémarrage de l'environnement doit être déclenché : Initiateurs de Redémarrage de l'Environnement

OAuth 2.0

OAuth 2.0 offre un mécanisme d'authentification plus moderne et sécurisé et est donc l'approche recommandée pour les environnements productifs.

Au lieu de transmettre les identifiants utilisateur, OAuth utilise des jetons d'accès. Ces jetons peuvent être limités en portée et en durée de vie, ce qui permet un contrôle nettement meilleur de l'accès et réduit les risques liés à l'exposition des identifiants.

Documentation : Activation d'OAuth 2.0 - BOC Docs
 

Flux OAuth 2.0

Selon le scénario d'intégration, différents flux OAuth sont utilisés : 

Type de Grant Client Credentials | BOC Developer Portal
Le flux Client Credentials est généralement utilisé pour la communication système-à-système. Dans ce cas, aucune interaction utilisateur n'est requise, et l'authentification est effectuée uniquement entre composants techniques. C'est l'approche la plus courante pour les intégrations backend et les processus automatisés.
 

Type de Grant Authorization Code | BOC Developer Portal
Le flux Authorization Code est nécessaire si un contexte utilisateur réel est requis. C'est généralement le cas lors de l'utilisation de Single Sign-On (SSO), où l'authentification est déléguée à un fournisseur d'identité. Seul ce flux permet une authentification basée sur l'utilisateur appropriée dans de tels scénarios.

Exigences du Type de Grant Authorization Code OAuth 2.0

Lors de l'utilisation d'OAuth 2.0, les conditions utilisateur suivantes doivent être remplies :

• Comme pour l'Basic Authentication, l'utilisateur impliqué doit être un utilisateur défini localement et ne doit pas être lié au SSO. 

• Cet utilisateur doit explicitement être configuré en tant qu'utilisateur technique dans les paramètres système.

• La "Connexion de Confiance" doit être activée.

• Accès au Référentiel configuré.

Lors de l'utilisation d'OAuth 2.0, les conditions système suivantes doivent être remplies :

La seconde partie de la configuration est effectuée via le connecteur, où le client OAuth est créé. Au cours de ce processus, l'ID client et le secret client sont générés et utilisés ultérieurement pour obtenir des jetons d'accès : Authentification | ADONIS

L'accès à l'API est ensuite contrôlé via des scopes, qui définissent précisément quelles opérations sont autorisées. Cela permet un modèle d'autorisation beaucoup plus défini comparé à l'Basic Authentication.

Veuillez noter : Après la configuration, un redémarrage de l'environnement doit être déclenché : Initiateurs de Redémarrage de l'Environnement
 

Recommandations

Pour les environnements productifs, OAuth 2.0 doit toujours être préféré en raison de son modèle de sécurité amélioré et de sa flexibilité.

L'Basic Authentication peut encore être utile pour des tests rapides ou des configurations initiales, mais elle ne doit pas être considérée comme une solution à long terme dans des environnements avec des exigences de sécurité élevées.

La création de clients OAuth séparés assure une séparation claire des droits d'accès et simplifie la maintenance. Les modifications peuvent alors être appliquées à une seule intégration sans affecter les autres.