Les noms d'utilisateur d'authentification Basic sont des métadonnées sensibles

Les noms d'utilisateur d'authentification Basic sont des métadonnées sensibles.

Cette affirmation peut sembler tatillonne, jusqu'au jour où il faut nettoyer les conséquences d'une exécution d'automatisation qui a copié billing-export@north-division dans une transcription shell, un journal CI, un prompt d'agent et un ticket d'incident. Le mot de passe peut être absent de ces quatre endroits. Un attaquant apprend tout de même qu'un locataire north-division existe, qu'il dispose d'une intégration d'export de facturation et que le compte atteint probablement une API historique donnée.

Les équipes classent souvent les données en deux catégories : les secrets et tout le reste. Cette séparation est trop grossière pour les API pilotées par des agents. Un nom d'utilisateur, un identifiant de locataire, un nom d'hôte, un chemin d'API et un code de réponse peuvent sembler inoffensifs pris séparément. Ensemble, ils décrivent une structure de comptes qui mérite d'être attaquée. Traitez ces associations comme des métadonnées sensibles, surtout lorsqu'un agent peut copier le contexte beaucoup plus loin et beaucoup plus vite qu'une personne qui saisit une seule requête.

Un nom d'utilisateur peut révéler la structure du système de comptes

Un nom d'utilisateur Basic porte souvent plus d'informations que ne le laisse penser le nom du champ. Les systèmes historiques l'utilisent comme identifiant de connexion, code client, libellé de division, rôle de service, marqueur d'environnement ou identifiant composé, créé avant l'adoption d'un meilleur modèle d'identité.

Voici quelques exemples :

acme-east:password
svc-payroll-prod:password
tenant-48291-export:password
[email protected]:password

La première valeur indique un client et une séparation régionale. La deuxième révèle une capacité interne et un environnement. La troisième expose un identifiant de locataire et une fonction. La quatrième révèle une personne et sa relation avec un client. Faire tourner le mot de passe corrige la moitié correspondant au mot de passe. Cela ne fait pas disparaître la cartographie du compte qui a été copiée.

C'est important, car les attaquants ne commencent pas toujours par un identifiant. Ils commencent par une liste de cibles. Un nom d'utilisateur reconnaissable les aide à rédiger une demande de réinitialisation crédible, à deviner des comptes associés, à rechercher des fuites d'identifiants, à sonder un chemin propre à un client ou à mettre la pression sur le support avec des détails qui semblent internes.

Ne balayez pas ce risque d'un revers de main au motif que le nom d'utilisateur n'est valable qu'avec un mot de passe. Savoir que svc-orders-import-prod existe ne revient pas à le contrôler, mais c'est bien plus utile que de ne rien savoir. La sécurité devient coûteuse lorsque les équipes attendent qu'un champ soit un identifiant complet avant de le protéger.

La classification appropriée dépend du contexte. Un nom d'utilisateur générique utilisé par tous les comptes de bac à sable demande peut-être peu de protection. Une identité de service limitée à un locataire et associée à un point de terminaison interne mérite une gestion beaucoup plus stricte. Documentez cette distinction pour chaque intégration au lieu d'appliquer une étiquette générale après une fuite.

L'authentification Basic associe le nom du compte à chaque appel

L'authentification Basic envoie une valeur user-id:password encodée en Base64 dans l'en-tête HTTP Authorization. Base64 modifie la représentation. Il ne masque pas les octets d'origine à quiconque peut lire l'en-tête.

Une requête classique ressemble à ceci :

GET /v1/exports/monthly HTTP/1.1
Host: api.legacy.example
Authorization: Basic c3ZjLWJpbGxpbmctZXhwb3J0LXByb2Q6cmVkYWN0ZWQ=
Accept: application/json

Le texte encodé contient les deux éléments chaque fois que le client appelle l'API. C'est cette répétition que les équipes oublient. Un jeton bearer peut lui aussi révéler le contexte du compte, mais de nombreuses intégrations Basic utilisent des noms d'utilisateur lisibles qui l'expriment clairement après décodage.

RFC 7617 définit ce mécanisme et précise ici deux points importants. Le premier signe deux-points sépare l'identifiant utilisateur du mot de passe, si bien qu'un deux-points dans le nom d'utilisateur est invalide. Les caractères de contrôle sont également interdits. Un fournisseur historique peut donc accepter une convention de compte visuellement pratique, mais incapable de passer dans un en-tête Basic conforme aux standards. N'inventez pas une règle d'échappement en espérant que toutes les bibliothèques l'interpréteront de la même manière.

Le second point concerne les caractères. RFC 7617 autorise un serveur à annoncer UTF-8 dans son challenge, mais ce signal reste indicatif et de nombreux systèmes anciens gèrent mal les identités non ASCII. Si un compte contient des caractères accentués, des règles de casse ou de l'Unicode transformé, testez la paire client-serveur exacte avant la mise en production. Une incompatibilité peut provoquer un échec d'authentification que quelqu'un tentera de « corriger » en déversant l'identifiant complet dans une sortie de débogage.

L'authentification Basic nécessite aussi HTTPS. OWASP décrit les identifiants Basic comme encodés et non chiffrés, et recommande TLS partout où Basic est utilisé. TLS protège la connexion pendant son transport. Il ne protège pas un en-tête après son enregistrement par une bibliothèque cliente, un proxy inverse, un agent de traçage, un gestionnaire d'erreurs ou un outil de débogage.

Les identifiants de locataire et les points de terminaison deviennent dangereux ensemble

Un identifiant de locataire peut n'être qu'un nombre opaque. Un point de terminaison peut n'être qu'un chemin générique. Ensemble, ils peuvent identifier la fonction métier d'un client et le système qui la prend en charge.

Supposons qu'un agent reçoive cette instruction :

Pour le locataire 48291, appelez https://ledger.internal.example/v2/reconciliation/import
avec le nom d'utilisateur tenant-48291-ledger-import.

Même si un autre composant injecte le mot de passe, l'instruction donne à l'agent un locataire, un hôte, une opération et une identité de service. L'agent peut citer cette instruction dans ses notes de travail. Un wrapper d'outil peut l'enregistrer. Une transcription de modèle peut la conserver. Un développeur peut copier l'erreur dans un canal de discussion. Le mot de passe est resté invisible, mais la structure du compte ne l'est pas.

L'exposition augmente lorsque les noms suivent une grammaire prévisible. Si un nom d'utilisateur est tenant-48291-ledger-import, il est logique de supposer qu'il existe peut-être tenant-48291-ledger-export, tenant-48291-reporting ou les mêmes rôles pour d'autres locataires. La prévisibilité est pratique pour les opérateurs et utile pour l'énumération. Il n'est pas nécessaire d'abandonner toutes les conventions de nommage, mais il faut reconnaître le moment où cette convention transforme un nom divulgué en requête d'annuaire.

Les couples hôte-chemin fournissent eux aussi des informations. /admin/users, /payroll/export, /claims/submit et /archive/retention révèlent des types de travail différents, même avec un nom d'hôte neutre. Un hôte associé à un chemin et à un locataire révèle souvent assez d'informations pour rendre crédible un message d'hameçonnage ou une tentative d'usurpation auprès du support.

Classez le tuple, pas seulement ses champs :

• identité de service et identifiant de locataire
• identité de service et nom d'hôte
• identifiant de locataire et chemin du point de terminaison
• chemin du point de terminaison et corps de réponse ou texte d'erreur
• horodatage et enregistrement d'une action réussie

C'est une règle plus précise que « expurgez les mots de passe ». Elle explique pourquoi une ligne de journal qui ne contient aucun secret littéral peut tout de même être dangereuse à envoyer dans un système d'observabilité largement accessible.

Les agents copient du contexte là où les clients ordinaires ne le font pas

Un client d'API ordinaire reçoit généralement une URL, un nom de compte et un mot de passe par un chemin de configuration étroit. Un agent IA traite les instructions comme du texte. Il peut inspecter un dépôt, lire un ticket, exécuter une commande, interpréter une erreur et rédiger un résumé. Chaque passage peut conserver des identifiants qu'un client traditionnel n'aurait jamais besoin d'afficher.

Le risque ne vient pas du fait que les agents seraient particulièrement négligents. Il vient du fait que les workflows d'agents rendent le contexte transportable par conception. La fonction qui permet à un agent de raisonner sur une note de déploiement et une réponse d'API lui permet aussi de transporter des noms de locataires et des schémas de points de terminaison dans des entrées d'outils, des transcriptions ou des correctifs générés.

Un échec courant ressemble à ceci :

1. Un développeur place un nom d'utilisateur Basic et un code de locataire dans un fichier .env local, car le mot de passe vient d'un coffre de secrets.
2. L'agent lit le fichier pour comprendre une intégration en échec.
3. L'API renvoie une réponse 401 détaillée qui répète le nom d'utilisateur et le locataire.
4. L'agent rédige un rapport de dépannage contenant l'extrait de configuration et l'erreur.
5. Le développeur copie ce rapport dans un ticket visible par un groupe plus large.

Personne n'avait l'intention de publier des identifiants. Pourtant, le ticket contient maintenant un schéma de nommage valide, un locataire, un hôte, un chemin, un rôle de service et une période où l'intégration était active. Ce contexte suffit à créer un risque supplémentaire.

Ne résolvez pas le problème en interdisant aux agents de voir toute chaîne non secrète. Cela bloque les tâches utiles et échoue généralement en pratique. Décidez plutôt des informations nécessaires à chaque action. Un agent qui doit demander un export mensuel peut avoir besoin d'un nom d'action abstrait et d'un mois. Il n'a pas besoin du nom d'utilisateur Basic, du mot de passe, de la règle de routage du locataire ni de l'URL cible brute.

La question de conception devient alors : « Quelle est la description d'action minimale dont l'agent a besoin pour produire la requête voulue ? » C'est cette question qui permet de garder la structure du compte hors de la fenêtre de contexte de l'agent.

Gardez les informations d'identité hors des prompts et des dépôts

Un prompt est un mauvais magasin de configuration. Les fichiers source, les exemples de commandes curl, les modèles de tickets, les alias shell et les fixtures de test le sont aussi. Tous se déplacent plus loin que ne le prévoit leur auteur.

Commencez par séparer trois éléments que les équipes confondent souvent :

1. Le matériel d'identification regroupe le nom d'utilisateur et le mot de passe utilisés pour s'authentifier.
2. Les métadonnées de routage indiquent où va une requête, par exemple un hôte, une partition de locataire ou une famille de points de terminaison.
3. L'intention de l'action désigne l'opération métier, comme « télécharger le fichier de rapprochement de mars ».

Un humain ou un agent peut souvent exprimer l'intention de l'action sans voir les deux autres catégories. C'est la frontière à privilégier. Si une API historique impose un routage via un hôte ou un nom d'utilisateur propre au locataire, conservez la correspondance dans le composant qui exécute la requête, pas dans le prompt qui la demande.

Évitez les exemples .env bruts comme celui-ci dans un dépôt :

LEGACY_API_URL=https://tenant-48291.api.legacy.example/v2/payroll/export
LEGACY_API_USER=tenant-48291-payroll-export
LEGACY_API_PASSWORD=replace-me

Le placeholder replace-me ne rend pas l'exemple sûr. L'URL et le nom d'utilisateur documentent toujours un schéma d'intégration propre à un client. Un exemple copié peut aussi devenir une configuration de production, généralement sous la pression d'une échéance.

Utilisez plutôt un contrat local abstrait :

actions:
  export_monthly_payroll:
    account_ref: payroll-export-production
    target_ref: payroll-export-api
    inputs:
      - tenant_alias
      - month

Les libellés account_ref et target_ref doivent être suffisamment opaques pour qu'un lecteur du dépôt ne puisse pas déduire le client, le nom d'hôte ou le rôle de service. L'exécuteur les résout localement. L'agent ne reçoit tenant_alias que si l'action en a réellement besoin, et cet alias ne devrait pas être un identifiant de locataire de production lorsqu'une correspondance locale permet de s'en passer.

Cette approche évite aussi une erreur fréquente lors d'une migration : déplacer le mot de passe dans un gestionnaire de secrets tout en laissant le nom d'utilisateur, l'URL cible et le code client en dur dans l'application. C'est mieux que de valider un mot de passe dans le dépôt, mais la structure reste visible par chaque développeur, journal de build et export d'outil d'analyse du code.

Utilisez des alias qui ne transforment pas une fuite en annuaire

Les noms opaques ne sont pas magiques, mais ils réduisent les informations fournies par une divulgation accidentelle. Le nom du compte doit décrire son usage au petit groupe qui l'administre, pas annoncer une relation client à tous les systèmes qui le voient.

Comparez ces alias de service :

mauvais :  acme-east-payroll-export-prod
meilleur : svc-47f2-export-p1

Le second conserve un préfixe de service lisible et un marqueur d'environnement. C'est souvent pratique. Les informations utiles s'arrêtent là. Un registre protégé distinct peut associer svc-47f2-export-p1 au client, au propriétaire, au point de terminaison, aux permissions et à l'enregistrement de rotation.

Ne considérez pas les alias d'apparence aléatoire comme un substitut à l'autorisation. Un attaquant qui possède le mot de passe peut toujours s'authentifier, et un employé qui a accès au registre peut toujours voir la correspondance. Les alias réduisent la divulgation inutile. Le principe du moindre privilège et les revues d'accès contrôlent ce que le compte peut faire.

Il arrive qu'un fournisseur impose le format du nom d'utilisateur. Certaines API anciennes exigent un numéro de client, une adresse e-mail ou une valeur composée qui inclut une région. Dans ce cas, admettez que le champ est sensible et adaptez la gestion autour de lui. Ne prétendez pas que la valeur est publique simplement parce que vous ne pouvez pas la renommer.

Gardez les identifiants imposés par le fournisseur dans la frontière des identifiants et rendez les sorties en aval aussi sobres que possible. Un exécuteur de requête peut renvoyer export accepted avec un identifiant de tâche. Il n'a pas besoin de répéter le nom d'utilisateur transmis, l'URL cible complète ou la valeur de routage du locataire à l'agent appelant.

Les journaux ont besoin d'une piste d'audit, pas d'un annuaire de comptes

Les journaux de sécurité doivent fournir assez de détails pour répondre à ces questions : qui a lancé l'action, que s'est-il passé, quand et avec quel résultat ? Ils n'ont pas besoin de conserver chaque octet envoyé par le client. Les recommandations de journalisation d'OWASP déconseillent explicitement l'enregistrement d'informations sensibles comme les mots de passe, les identifiants de session et les détails système superflus, tout en demandant que les événements d'authentification et de contrôle d'accès soient enregistrés.

La tension est réelle. Si vous supprimez tout, les opérateurs ne peuvent pas enquêter sur un incident. Si vous conservez indéfiniment les en-têtes bruts et les URL complètes, vos journaux deviennent un annuaire de comptes interrogeable.

Utilisez une structure qui sépare la corrélation opérationnelle des métadonnées sensibles :

{
  "event": "legacy_api_call",
  "action": "export_monthly_payroll",
  "request_id": "req_01J...",
  "actor_run": "run_01J...",
  "credential_ref": "cred_4c91",
  "target_ref": "target_a77e",
  "result": "denied",
  "http_status": 401,
  "reason": "authentication_failed",
  "occurred_at": "2026-07-22T14:03:21Z"
}

Ces références permettent aux opérateurs autorisés de relier les événements à un inventaire protégé. Elles ne placent ni le nom d'utilisateur, ni l'identifiant de locataire, ni le point de terminaison brut, ni l'en-tête Authorization dans chaque événement. L'accès à l'inventaire doit être plus restreint que l'accès ordinaire aux journaux.

Ne hachez pas un nom d'utilisateur en pensant que le problème est réglé. Le hachage déterministe d'un espace de noms d'utilisateur réduit et structuré est souvent devinable, et un hachage stable permet toujours de suivre un compte d'un enregistrement à l'autre. Pour la corrélation, utilisez une référence d'identifiant aléatoire attribuée par votre système. Faites tourner ou retirez cette référence lorsque vous faites tourner l'identifiant.

Soyez prudent avec les diagnostics d'échec. Voici une mauvaise réponse à transmettre :

401 for tenant-48291-payroll-export at /v2/payroll/export: user exists but password rejected

Elle confirme un compte, un locataire, un chemin et un résultat de validation. Une meilleure gestion interne conserve le diagnostic exact du fournisseur dans un dossier de support restreint si vous en avez réellement besoin, tandis que la piste générale enregistre authentication_failed. L'agent doit recevoir un échec bref lui indiquant d'arrêter et de demander de l'aide, pas un nouvel indice pour essayer des variantes.

L'expurgation et la minimisation répondent à des problèmes différents

L'expurgation retire une valeur dangereuse connue après qu'une personne ou un système l'a déjà manipulée. La minimisation empêche la valeur d'entrer dans un endroit où elle n'a rien à faire. Vous avez besoin des deux, et les confondre mène à de mauvaises conceptions.

Un filtre d'en-têtes peut remplacer ceci :

Authorization: Basic c3ZjLWJpbGxpbmctZXhwb3J0LXByb2Q6cmVkYWN0ZWQ=

par ceci :

Authorization: [REDACTED]

C'est nécessaire. Mais cela ne change rien au chemin, au nom d'hôte, au paramètre de locataire dans la requête, au corps 401 détaillé, au libellé de requête ou aux attributs de trace enregistrés à côté de l'en-tête. Un système qui se félicite d'expurger les mots de passe tout en conservant tenant-48291.api.legacy.example/payroll/export a réduit un risque et laissé une cartographie de compte exploitable.

La minimisation pose des questions plus difficiles avant l'exécution de la requête :

• L'agent a-t-il besoin de l'hôte cible réel ou seulement d'un nom d'action ?
• Le journal d'activité a-t-il besoin de l'identifiant de locataire ou seulement d'une référence protégée ?
• Le support a-t-il besoin de la réponse brute du fournisseur dans le flux de journaux ordinaire ?
• La requête doit-elle contenir le locataire dans l'URL si l'exécuteur peut le résoudre localement ?
• Une personne qui examine une approbation a-t-elle besoin de l'identité complète ou d'un libellé lisible qui ne révèle pas la structure ?

C'est ici que de nombreuses équipes font une recommandation populaire mais erronée : « Enregistrez toute la requête une fois, puis améliorez les filtres plus tard. » Elles le disent parce que le dépannage des API historiques est pénible et que les captures complètes répondent rapidement aux questions. Les données capturées deviennent ensuite des preuves permanentes dans les sauvegardes, les magasins analytiques, les environnements de test et les notes d'incident copiées. Créez plutôt un chemin de diagnostic restreint et temporaire pour une enquête précise. Ne faites pas de la capture brute généralisée le mode normal de fonctionnement.

Les API historiques ont besoin d'une frontière de confinement, pas d'une confiance aveugle

Vous ne pourrez peut-être pas remplacer l'authentification Basic ce trimestre. Un fournisseur peut ne prendre en charge qu'un seul style d'intégration. Un appareil d'entrepôt peut avoir une API figée depuis des années. La réponse pratique est le confinement, pas une déclaration optimiste selon laquelle l'API historique serait acceptable.

Placez l'identifiant Basic et la correspondance des identifiants derrière un composant qui exécute lui-même la requête HTTP. L'agent doit demander une action nommée avec des entrées structurées. Le composant sélectionne la cible, obtient l'identifiant, l'injecte dans l'en-tête, vérifie la portée prévue et renvoie un résultat limité.

Pour une action d'agent, un contrat utile ressemble à ceci :

{
  "action": "export_monthly_payroll",
  "tenant_alias": "tenant_ref_91ab",
  "month": "2026-06"
}

L'exécuteur peut valider le mois, résoudre tenant_ref_91ab dans une correspondance locale protégée et appeler le fournisseur. Il doit refuser les champs supplémentaires comme url, authorization, username et headers. Si les appelants peuvent remplacer ces champs, ils peuvent acheminer un identifiant de confiance vers un hôte arbitraire ou transformer une action étroitement définie en client HTTP brut.

Cette restriction est importante pour les erreurs de type SSRF comme pour l'exposition des identifiants. Une URL fournie par l'utilisateur n'est pas une simple commodité lorsque l'exécuteur détient des identifiants. La cible doit provenir d'une définition contrôlée et les redirections doivent être traitées avec la même prudence. Ne suivez pas une redirection vers une nouvelle origine en conservant l'en-tête Authorization.

Cette frontière doit aussi gérer les nouvelles tentatives. Un agent mal conçu peut réessayer une réponse 401 avec une entrée modifiée ou invoquer plusieurs fois une opération après un délai d'attente. L'exécuteur doit distinguer une nouvelle tentative de transport sûre d'un échec d'authentification ou d'un résultat d'écriture inconnu. Pour un point de terminaison historique non idempotent, renvoyez un état qui impose une vérification humaine plutôt que de renvoyer la même requête parce que l'agent l'a demandée avec assurance.

Sallyport correspond à ce modèle lorsqu'un agent compatible MCP doit appeler une API HTTP sans recevoir lui-même l'identifiant Basic. Son canal HTTP injecte les identifiants Basic dans l'application, tandis que ses contrôles par session et par appel permettent à une personne de décider quand une exécution d'agent peut utiliser ce compte. L'agent reçoit le résultat de l'action, pas un nom d'utilisateur ou un mot de passe en clair qu'il pourrait réutiliser ailleurs.

L'approbation doit montrer assez de contexte pour repérer une mauvaise action

Une boîte de dialogue qui dit seulement « Autoriser l'appel API ? » n'aide pas. Une boîte de dialogue qui affiche le nom d'utilisateur Basic complet, le locataire, l'URL complète et le corps brut de la requête en révèle trop. Le réviseur a besoin d'une description concise qui rende une mauvaise action évidente sans exposer toute la structure du compte.

Affichez le nom de l'action, un libellé de cible protégé, un libellé de locataire choisi pour le réviseur, le type d'opération et sa conséquence générale. Par exemple :

Autoriser export_monthly_payroll ?
Cible : service d'export de paie
Locataire : locataire Finance 7
Opération : créer l'export de juin 2026
Exécution de l'agent : processus local de développement signé

Le réviseur dispose ainsi de suffisamment d'informations pour remarquer un mois, une fonction ou une cible inattendus. L'enregistrement d'approbation ne révèle ni le nom d'hôte du fournisseur, ni le numéro du locataire, ni le nom d'utilisateur de service.

Le libellé affiché doit être gouverné. Si « locataire Finance 7 » apparaît dans une équipe qui ne compte qu'un seul client financier, il peut encore identifier ce client. Adaptez les libellés au groupe qui les voit. La sécurité ne consiste pas à remplacer chaque nom utile par un code opaque que les réviseurs ne comprennent pas.

Pour les comptes Basic sensibles, exigez une approbation à chaque utilisation lorsque l'action peut déplacer de l'argent, exporter des données réglementées, modifier des accès ou contacter un tiers. Une approbation par session est plus pratique pour une courte exécution qui effectue de nombreuses lectures à faible risque. Le choix doit dépendre de l'autorité du compte et des conséquences de l'action, pas du simple fait que l'authentification Basic est ancienne.

Conservez une trace vérifiable de la décision d'approbation et de l'appel qui en résulte. Un enregistrement inviolable n'est utile que s'il décrit l'acteur, l'action, le résultat et l'état de l'approbation sans devenir une autre copie de la cartographie des comptes. Les journaux Sessions et Activité distincts de Sallyport reposent sur cette séparation, les deux vues étant produites à partir de son journal d'audit chiffré et chaîné par hachage.

Rendez la collecte de la structure des comptes difficile dès le départ

La solution n'est pas un gigantesque document de politique qui dit de « manipuler les métadonnées avec prudence ». Faites du chemin sûr celui que les développeurs et les agents empruntent naturellement.

Inventoriez chaque intégration Basic et répondez, pour chacune, aux questions suivantes : que révèle le nom d'utilisateur ? Contient-il une personne, un client, un environnement, un produit ou un rôle ? Quel couple hôte-point de terminaison rend cette valeur plus révélatrice ? Où ces valeurs apparaissent-elles aujourd'hui ? Quel appelant a réellement besoin de les voir ?

Supprimez ensuite les copies faciles. Remplacez les extraits curl bruts par des exemples d'actions. Remplacez les noms de fixtures propres à un locataire par des alias de test neutres. Bloquez les en-têtes Authorization et les informations utilisateur des URL dans les journaux applicatifs. Gardez les diagnostics complets du fournisseur hors des sorties visibles par l'agent. Refusez les cibles fournies par l'utilisateur à la frontière des identifiants. Donnez au support un moyen contrôlé d'obtenir les détails lorsqu'un incident le justifie.

RFC 9110 indique que les émetteurs ne doivent pas générer de références URI HTTP ou HTTPS contenant des informations utilisateur sous la forme user:password@host, et avertit que les implémentations peuvent exposer un identifiant ou un mot de passe lorsqu'elles utilisent cette forme dans une configuration ou des options de commande. C'est un avertissement utile au-delà des URL : les informations d'identité placées dans des champs textuels pratiques ont tendance à être copiées dans des endroits où elles n'avaient jamais vocation à se trouver.

L'authentification Basic peut rester en place parce qu'un fournisseur n'a pas évolué. Votre propre gestion, elle, n'a pas à rester figée. Dès que vous traitez les noms d'utilisateur, les identifiants de locataire et les couples de points de terminaison comme des métadonnées sensibles, vous cessez de remettre à l'agent l'annuaire des comptes avec sa tâche.