Résumé

  • Un service peut découvrir, au moment d’un appel, que l’authentification associée au jeton ne convient pas à l’opération. Un mécanisme commun lui permet de préciser ce qu’il attend.
  • Cette interopérabilité ne garantit pas que l’utilisateur dispose des moyens nécessaires, ni que les politiques du service et du fournisseur d’identité soient compatibles.
  • Il faut gouverner la capacité à provoquer une nouvelle interaction : conditions réalisables, fin des tentatives inutiles, informations révélées et responsabilité de la charge imposée.

Le problème finit souvent ailleurs

Imaginons un service d’assistance face à un utilisateur qui affirme s’être déjà authentifié plusieurs fois. L’application indique pourtant qu’une nouvelle vérification est nécessaire. L’équipe d’identité constate des échanges réussis. Le propriétaire de l’API confirme que sa règle de sécurité fonctionne. Chacun décrit correctement son fragment du système ; personne n’a encore expliqué comment l’utilisateur peut terminer son travail.

Il s’agit d’un scénario d’analyse, pas d’un incident observé. Son intérêt tient au déplacement des responsabilités. Le service qui décide qu’une opération exige davantage d’assurance n’est pas nécessairement celui qui fournit les moyens d’authentification ou finance l’assistance. Une modification locale peut donc produire une charge très éloignée de son auteur.

Interdire au service de revoir son exigence serait une mauvaise réponse. Certaines caractéristiques d’une opération ne sont connues qu’au dernier moment. Tout figer lors de l’émission initiale du jeton priverait la décision de ce contexte. La bonne question porte plutôt sur les conditions dans lesquelles le service peut transformer son appréciation du risque en travail supplémentaire pour autrui.

RFC 9470, publié en septembre 2023, prévoit un refus accompagné d’exigences de contexte ou de fraîcheur de l’authentification. Le client transmet la demande au serveur d’autorisation, puis le service examine le résultat. Le document souligne toutefois que les politiques peuvent aboutir à des conditions impossibles à remplir et que la capacité à déclencher une interaction peut être détournée. Le langage du dialogue n’est pas un accord sur tout ce qu’il est raisonnable de demander.

Une exigence n’est pas une capacité

Lors d’un achat, la mention « authentification renforcée prise en charge » peut sembler suffisante. Elle établit au mieux une capacité du produit. Elle ne prouve pas que les personnes concernées possèdent un équipement donné, sont correctement inscrites ou peuvent utiliser cet équipement dans leur situation du moment.

L’écart est important. Une démonstration réalisée avec un compte administrateur préparé à l’avance ne dit pas grand-chose du parcours d’un utilisateur en déplacement, en cours d’inscription ou privé de son appareil habituel. Ces cas ne justifient pas automatiquement une réduction du niveau demandé. Ils obligent à expliciter le parcours prévu lorsque l’exigence ne peut pas être satisfaite immédiatement.

Le mot « renforcer » ajoute une ambiguïté. Il évoque une échelle unique sur laquelle chaque étape serait meilleure que la précédente. Or les contextes acceptables dépendent de la politique du service. Une méthode adaptée à une opération ne devient pas, par son seul intitulé, un substitut universel à toutes les autres.

Le contrat entre équipes doit donc porter sur des conditions concrètes : ce que le service demande, ce que le fournisseur peut attester et ce que les populations visées peuvent effectivement accomplir. Une liste de fonctions disponibles ne remplace pas cet accord.

Lorsque le souhait est pris pour une obligation

OpenID Connect Core distingue la demande volontaire d’un contexte d’authentification et la demande essentielle de valeurs précises, lorsque le mécanisme correspondant est pris en charge. Il traite aussi séparément l’âge maximal de l’authentification et la présentation d’une interface à l’utilisateur.

Cette distinction peut paraître minutieuse. Elle devient déterminante si un service considère un contexte comme indispensable, tandis que le fournisseur traite sa transmission comme une préférence. Une réponse peut alors être correcte dans un dialogue et insuffisante dans l’autre.

L’erreur ne serait pas de renvoyer honnêtement le contexte obtenu. Elle serait de présenter cet échange comme l’assurance que l’opération demandée pourra désormais réussir. Le résultat attendu par l’API doit rester distinct du résultat effectivement atteint pendant l’authentification.

Une nouvelle émission de jeton peut rendre l’écart moins visible. Quelque chose de neuf arrive, le parcours semble avancer, mais la propriété recherchée n’a pas changé. L’interface invite alors à recommencer sans pouvoir dire ce que la tentative suivante rendrait possible.

Un échec explicite peut éviter une mauvaise boucle

La spécification OpenID relative aux exigences d’authentification non satisfaites définit un signal d’échec, notamment pour le cas d’un contexte essentiel que le fournisseur ne peut pas fournir. RFC 9470 recommande, pour le parcours d’accès qu’il décrit, de traiter le contexte demandé comme nécessaire afin de ne pas délivrer indéfiniment des jetons que le service refusera.

La recommandation ne fixe pas un nombre universel de tentatives. Ce nombre, les circonstances d’une reprise et les alternatives autorisées relèvent de l’exploitation. Il faut les décider plutôt que laisser l’utilisateur découvrir la limite par épuisement.

Une nouvelle tentative devrait avoir une raison. Un équipement redevenu disponible, une inscription achevée ou un événement d’authentification pertinent peuvent modifier la situation. Rejouer sans changement une exigence que le fournisseur ne sait pas satisfaire n’offre pas la même perspective.

Sortir de cette boucle ne signifie pas contourner la politique. Un refus clair, assorti d’une voie d’assistance ou d’une alternative approuvée, n’équivaut pas à accorder l’accès. La distinction permet de préserver la condition de sécurité sans transformer une incompatibilité en série d’ordres incompréhensibles adressés à l’utilisateur.

Le renouvellement n’efface pas l’ancien événement

Le profil JWT des jetons d’accès, RFC 9068, distingue le moment d’émission du jeton des informations relatives à l’authentification. Pour les jetons issus d’une même réponse d’autorisation, ces dernières restent fixées à travers les opérations de renouvellement ou d’échange concernées. Un nouvel objet n’atteste donc pas, à lui seul, une nouvelle action de l’utilisateur.

Le même profil demande au client de ne pas fonder sa logique sur l’examen du contenu du jeton d’accès. Son format appartient à l’accord entre émetteur et ressource et peut changer. Une application ne devrait pas tenter de réparer une mauvaise coordination en interprétant opportunément des champs qu’elle aperçoit aujourd’hui.

L’introspection définie par RFC 7662 offre au service autorisé une autre voie d’accès à l’état et aux métadonnées du jeton. RFC 9470 y ajoute les informations d’authentification utiles à son mécanisme. Mais « actif » ne signifie toujours pas que chaque condition propre à la requête est satisfaite.

Le choix entre information portée par le jeton et introspection ne résout donc pas la question de gouvernance. Dans les deux cas, il faut savoir qui produit l’information, qui l’évalue et quel événement permet réellement de changer la réponse. Sinon, un succès technique local masque encore un parcours sans issue.

La demande révèle aussi ce que le service protège

Une réponse détaillée aide l’application à choisir la suite. Elle peut également renseigner son destinataire sur l’utilisateur, la ressource ou le contexte. Une exigence réservée à certaines catégories de comptes risque, selon les circonstances, de révéler une distinction que l’organisation aurait préféré garder discrète.

Ce risque figure dans les considérations de sécurité du protocole. Il ne prouve ni une exploitation effective ni la vulnérabilité d’un service particulier. Il impose cependant une décision : quelles informations transmettre, après quelles vérifications et à quel interlocuteur ?

Le protocole permet un ordre de traitement dans lequel le défi précède la validation du jeton. Cette possibilité ne constitue pas une recommandation générale de dévoiler les exigences à tout appelant. Elle expose un arbitrage entre l’aide apportée au parcours et ce qu’un interlocuteur encore peu établi peut apprendre.

Les outils d’assistance méritent la même attention. Expliquer un refus ne nécessite pas automatiquement de centraliser tous les jetons et attributs personnels. Des diagnostics ciblés peuvent distinguer un contexte indisponible d’une erreur de transport. Leur contenu, leurs accès et leur durée de conservation doivent rester proportionnés.

Compter les sollicitations ne mesure pas le résultat

Une hausse du nombre de vérifications peut accompagner une bonne décision de sécurité, une mauvaise intégration ou une règle irréalisable. Le chiffre est descriptif ; il ne tranche pas entre ces situations.

L’indicateur utile porte sur la tâche accomplie sous les conditions attendues. Les exigences non satisfaites, les reprises inchangées et les abandons doivent rester visibles à côté des authentifications réussies. Il s’agit ici de pistes de suivi, pas de résultats mesurés.

Réduire le nombre de sollicitations à tout prix serait tout aussi trompeur. Une expérience apparemment fluide peut simplement avoir supprimé une condition nécessaire. Le choix n’oppose pas sécurité maximale et absence de friction : il consiste à concevoir une assurance pertinente, réalisable et assortie d’une issue intelligible.

Avant un déploiement, l’examen de quelques parcours légitimes difficiles peut mettre au jour les hypothèses cachées. Il ne certifiera pas tous les usages futurs. Il obligera au moins les propriétaires du risque, de l’identité et de l’expérience utilisateur à parler du même résultat, plutôt que de trois tableaux de bord.