Pourquoi un seul OTP ne couvre pas le Wi-Fi, le VPN et un registre

L’authentification unique promet une identité et moins de demandes, et la promesse se brise au troisième protocole. Le piège est de supposer qu’une authentification réussie produit un jeton que tout autre protocole peut présenter. L’accès Wi-Fi, l’entrée VPN et un registre de conteneurs exécutent chacun un échange différent, avec des publics et des durées de vie différents. Partager le compte est une décision d’annuaire ; partager le justificatif est une décision de protocole, et les protocoles sont rarement d’accord.

Trois échanges, trois propriétaires

Le Wi-Fi d’entreprise exécute une méthode EAP dans 802.1X, généralement terminée par un service RADIUS qui a sa propre vision de l’utilisateur ou de l’appareil. Une passerelle VPN s’authentifie via son propre flux pris en charge puis maintient une session avec son propre minuteur de réauthentification. Un registre répond à une requête non authentifiée par un défi nommant un service de jetons, un public et une portée, et le client échange son justificatif contre un jeton de courte durée.

Ce ne sont pas trois vues d’une même session. Chacun a son propre vérificateur, sa propre durée de vie et sa propre voie de révocation, ce qui explique qu’un changement de mot de passe dans l’annuaire puisse en laisser un fonctionnel et l’autre cassé. Traitez-les comme trois intégrations qui partagent par hasard un annuaire d’utilisateurs.

Ce que le SSO du navigateur porte et ce qu’il ne porte pas

Une session de navigateur chez un fournisseur d’identité est réellement utile : les applications qui y redirigent héritent de la connexion que l’utilisateur a déjà effectuée. Cela fonctionne parce que ces applications parlent les mêmes protocoles de redirection et de jetons et acceptent le même public. Un demandeur qui parle EAP n’a aucune redirection à suivre, et un client Docker qui reçoit un défi de registre ne demande pas un jeton d’identité OIDC. Le fournisseur d’identité ne peut se porter garant que des protocoles pour lesquels il a été conçu.

La panne est facile à voir dans les journaux quand on sait où regarder. Le fournisseur d’identité signale une connexion réussie alors que l’association Wi-Fi échoue encore, ou le registre renvoie 401 après un échange de jeton que le navigateur n’a jamais vu. Deux succès et un échec ne sont pas une contradiction ; ce sont trois authentifications distinctes.

Où un certificat remplace un code répété

Pour les appareils gérés, l’EAP par certificat supprime l’étape humaine sans supprimer l’identité : l’appareil présente un certificat, le service RADIUS le vérifie auprès de l’autorité émettrice, et la révocation a lieu auprès de cette autorité plutôt que dans un secret partagé. Le prix est un travail de cycle de vie, car les certificats expirent et doivent être renouvelés avant.

Les registres ont une répartition équivalente. Un utilisateur interactif peut se connecter une fois et laisser un assistant de justificatifs stocker le jeton obtenu, tandis que l’automatisation devrait utiliser un justificatif de service étroitement délimité ou une identité de charge de travail. Ni l’un ni l’autre ne devrait être le code à usage unique d’une personne copié dans un pipeline. L’assistant stocke un jeton pour un public de registre précis, il ne peut donc pas être redirigé vers la passerelle VPN en modifiant un fichier de configuration.

docker login registry.example.com

Comparez le coût de maintenance, pas le nombre de demandes

Un justificatif partagé semble bon marché parce que le travail est invisible jusqu’à ce qu’il échoue. Comptez plutôt ce que chaque option coûte sur un an : enrôlement, renouvellement, révocation, le rayon d’impact d’une fuite et le nombre de systèmes touchés au départ de quelqu’un. Une flotte de certificats coûte plus à construire et moins à exploiter à l’échelle ; un code copié ne coûte rien à démarrer et tout à défaire.

Choisissez ensuite par segment plutôt que globalement. Le Wi-Fi peut passer aux certificats, le VPN peut conserver son SSO pris en charge avec MFA, et le registre peut utiliser des jetons à portées explicites. Consignez le propriétaire, le public, la portée, l’expiration et la voie de révocation pour chacun, et les demandes tomberont là où il faut au lieu de partout à la fois. Cette consignation est aussi la réponse quand un auditeur demande quels systèmes font encore confiance à un mot de passe.